In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: simple-mux: Fix enum control bounds check

simplemuxcontrolput() rejects values greater than e->items, but enum control values are zero based. For the two-entry mux used by this driver, valid values are 0 and 1, so value 2 must be rejected as well.

Accepting e->items can store an invalid mux state, pass it to the GPIO setter, and pass it on to the DAPM mux update path where it is used as an index into the enum text array.

Use the same >= e->items check used by the ASoC enum helpers.

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: net2280: Fix double free in probe error path

usbinitializegadget() installs gadgetrelease() as the release callback for the embedded gadget device. The struct net2280 instance is therefore released through gadgetrelease() when the gadget device's last reference is dropped.

The probe error path calls net2280remove(), which tears down the partially initialized device and drops the gadget reference with usbputgadget(). Calling kfree(dev) afterwards can free the same object again.

Drop the explicit kfree() and let the gadget device release callback handle the final free. This issue was found by a static analysis tool I am developing.

In the Linux kernel, the following vulnerability has been resolved:

mm/damon/sysfs-schemes: delete tried region in regionsrmdirs()

DAMON sysfs maintains the DAMOS tried region directory objects via a linked list. When the user requests refresh of the directories, DAMON sysfs removes all the region directories first, and then generate updated regions directory on the empty space. The removal function (damonsysfsschemeregionsrmdirs()) only puts the kobj objects. Deletion of the container region object from the linked list is done inside the kobj release callback function.

If somehow the callback invocation is delayed, the list will contain regions list that gonna be freed. If the updated region directories creation is started in this situation, the list can be corrupted and use-after-free can happen.

Because the kobj objects are managed by only DAMON sysfs, the issue cannot happen in normal situation. But, such delays can be made on kernels that built with CONFIGDEBUGKOBJECTRELEASE. On the kernel, the issue can indeed be reproduced like below.

# damo start --damosaction stat # cd /sys/kernel/mm/damon/admin/kdamonds/0/ # for i in {1..10}; do echo updateschemestriedregions > state; done # dmesg | grep underflow [ 89.296152] refcountt: underflow; use-after-free.

Fix the issue by removing the region object from the list when decrementing the reference count.

Also update damossysfspopulateregiondir() to add the region object to the list only after the kobjectinitandadd() is success, so that fail of kobjectinitandadd() is not leaving the deallocated object on the list.

The issue was discovered [1] by Sashiko.

In the Linux kernel, the following vulnerability has been resolved:

Input: elani2c - validate firmware size before use

Ensure that the firmware file is large enough to contain the expected number of pages and the signature (which resides at the end of the firmware blob) before accessing them to prevent potential out-of-bounds reads.

In the Linux kernel, the following vulnerability has been resolved:

x86/ftrace: Relocate %rip-relative percpu refs in dynamic trampolines

With CONFIGCALLDEPTHTRACKING enabled on an x86 retbleed-affected platform (eg: Skylake), with retbleed=stuff, registering a dynamic ftrace trampoline crashes on the first call into the traced function:

BUG: unable to handle page fault for address: ffff88817ae18880 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 4b53067 P4D 4b53067 PUD 0 Oops: Oops: 0002 [#1] SMP PTI CPU: 3 UID: 0 PID: 187 Comm: usleep Not tainted 7.0.10 #243 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Code: 24 78 00 00 00 00 48 89 ea 48 89 54 24 20 48 8b b4 24 b8 00 00 00 48 8b bc 24 b0 00 00 00 48 89 bc 24 80 00 00 00 48 83 ef 05 <65> 48 c1 3d 1f a8 b6 02 05 48 8b 15 f6 00 00 00 4c 89 3c 24 4c 89 Call Trace: <TASK> ? findheldlock ? excpagefault ? lockrelease ? x64sysclocknanosleep ? lockdephardirqsonprepare ? tracehardirqson x64sysclocknanosleep dosyscall64 ? excpagefault ? calldepthreturnthunk entrySYSCALL64afterhwframe ... Kernel panic - not syncing: Fatal exception

This small reproducer allows to easily trigger the crash:

# echo 'p x64sysclocknanosleep' > /sys/kernel/tracing/kprobeevents # echo 1 > /sys/kernel/tracing/events/kprobes/px64sysclocknanosleep0/enable # usleep 1

Monitoring the crash under GDB points to the exact instruction in charge of incrementing the call depth:

sarq $5, %gs:x86calldepth(%rip)

This instruction matches the one inserted by the ftraceregscaller from ftrace64.S. This emitted code was likely working fine until the introduction of

59bec00ace28 ("x86/percpu: Introduce %rip-relative addressing to PERCPUVAR()"):

it has made the call depth accounting addressing relative to $rip, instead of being based on an absolute address.

As this code exact location depends on where the trampoline lives in memory, the corresponding displacement needs to be adjusted at runtime to actually correctly find the per-cpu x86calldepth value, otherwise the targeted address is wrong, leading to the page fault seen above.

Fix the %rip-relative displacement of the copied CALLDEPTHACCOUNT instruction (from ftraceregscaller) by calling textpokeapplyrelocation(), as it is done for example by the x86 BPF JIT compiler through x86calldepthemitaccounting(). This corrects both CALLDEPTHACCOUNT slots, in ftracecaller and ftraceregscaller.

[ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:

schedext: Avoid UAF in scxrootenableworkfn() init failure path

In scxrootenableworkfn(), puttaskstruct(p) is called before scxerror() dereferences p->comm and p->pid. If the iterator's reference is the last drop, the task is freed synchronously and the deref becomes a UAF.

Move puttaskstruct() past scxerror().

In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: fix double free in rvureprsrcinit()

rvureprsrcinit() allocates queue memory before calling otx2inithwresources(). When hardware resource setup fails, otx2inithwresources() already unwinds the partially initialized SQ, CQ, and aura state before returning an error. The representor error path then calls otx2freehwresources() again and can free the same resources a second time.

Fix this by splitting the cleanup labels so that a failure from otx2inithwresources() only releases queue memory. Keep the otx2freehwresources() call for failures that happen after hardware resource initialization completed successfully.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.

Runtime validation was not performed because reproducing this path requires OcteonTX2 representor hardware.

In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: CGX: add bounds check to cgxspeedmbps index

cgxspeedmbps has 13 elements but RESPLINKSTATSPEED can yield values 0-15. If it returns a value >= 13, this causes an out-of-bounds array access. Add a bounds check and default to speed 0 if the index is out of range.

In the Linux kernel, the following vulnerability has been resolved:

octeontx2-pf: avoid double free of pool->stack on AQ init failure

otx2poolaqinit() frees pool->stack when mailbox sync or retry allocation fails, but leaves the pointer unchanged. Later, otx2sqaurapoolinit() unwinds the partial setup through otx2aurapoolfree(), which frees pool->stack again. The CN20K-specific cn20kpoolaqinit() implementation has the same bug in its corresponding error path.

Set pool->stack to NULL immediately after the local free so the shared cleanup path does not free the same stack again while cleaning up partially initialized pool state.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.

Runtime validation was not performed because reproducing this path requires OcteonTX2/CN20K hardware.

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: consume only present negotiated TTLM maps

ieee80211tidtolinkmapsizeok() validates negotiated TTLM elements against the number of link-map entries indicated by linkmappresence. ieee80211parsenegttlm() must consume the same layout.

The parser advanced its cursor for every TID, including TIDs whose presence bit is clear and therefore have no map bytes in the element. A sparse map can then make a later present TID read past the validated element.

The bad bytes land in negttlm->{up,down}link[tid] but are gated by validlinks before being applied to driver state, so a peer cannot turn the read into a policy change. Under KUnit + KASAN with an exact-sized element allocation the OOB read is reported as a slab-out-of-bounds; whether the same trigger fires under the production RX path depends on surrounding allocator state.

Advance the cursor only when the current TID has a map present.

In the Linux kernel, the following vulnerability has been resolved:

spi: ti-qspi: fix use-after-free after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to clear the DMA channel pointer also if buffer allocation fails to avoid passing a pointer to the released channel to the DMA engine (or trying to free the channel a second time on late probe errors or driver unbind).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Validate payload length and linkindex in dcprocessdmubauxtransferasync

[Why&How] dcprocessdmubauxtransferasync() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy.

Additionally, linkindex is used to dereference dc->links[] without bounds checking against dc->linkcount, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for linkindex before it is used.

(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)

In the Linux kernel, the following vulnerability has been resolved:

batman-adv: bla: fix reportwork leak on backbonegw purge

batadvblapurgebackbonegw() removes stale backbone gateway entries, but fails to properly handle their associated reportwork:

- If reportwork is running, the purge must wait for it to finish before freeing the backbonegw, otherwise the worker may access freed memory (e.g. batpriv). - If reportwork is pending, the purge must cancel it and release the reference held for that pending work item.

The previous implementation called hlistforeachentrysafe() inside a spinlockbh() section, but cancelworksync() may sleep and therefore cannot be called from within a spinlock-protected region.

Restructure the loop to handle one entry per spinlock critical section: acquire the lock, find the next entry to purge, remove it from the hash list, then release the lock before calling cancelworksync() and dropping the hashentry reference. Repeat until no more entries require purging.

In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix overrun check in netfsextractuseriter()

Fix netfsextractuseriter() so that if ioviterextractpages() overfills pages[], then those pages don't get included in the iterator constructed at the end of the function. If there was an overfill, memory corruption has already happened.

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: xsk: Fix unlocked writing to ICOSQ

During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected.

There are 2 such races:

A) mlx5etriggerirq() is called while mlx5exskallocrxmpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napicompletedone(). At this point the NAPI can be scheduled on a different CPU. Like this:

CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napicompletedone() clears SCHED mlx5ecqarm(...) napischeduleprep() sets SCHED mlx5enapipoll() mlx5exskallocrxmpwqe() mlx5eicosqsynclock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5etriggerirq(&c->icosq) wqeinfo[pi] = {NOP, 1} mlx5epostnop() advances sq->pc

B) mlx5etriggerirq() is called on the ICOSQ when mlx5etriggernapiicosq() is running.

The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked.

This issue was noticed in the wild with the following splat:

netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/enrx.c:826 [...] [...] Call Trace: <IRQ> mlx5enapipoll+0x11d/0x7f0 [mlx5core] napipoll+0x30/0x200 ? skbdeferfreeflush+0x9c/0xc0 netrxaction+0x2fe/0x3f0 handlesoftirqs+0xd8/0x340 irqexitrcu+0xbc/0xe0 commoninterrupt+0x85/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2

In the Linux kernel, the following vulnerability has been resolved:

crypto/krb5, rxrpc: Fix lack of pre-decrypt/pre-verify length checks

Change the krb5 crypto library to provide facilities to precheck the length of the message about to be decrypted or verified.

Fix AFRXRPC to make use of this to validate DATA packets secured with RxGK.

In the Linux kernel, the following vulnerability has been resolved:

phy: qcom: qmp-usbc: Fix out-of-bounds array access in dp swing config

swingtbl and preemphasistbl are 4x4 arrays (valid indices 0-3), but the boundary check uses "> 4" instead of ">= 4", allowing index 4 to cause an out-of-bounds access.

In the Linux kernel, the following vulnerability has been resolved:

net: qualcomm: rmnet: fix endpoint use-after-free in rmnetdellink()

rmnetdellink() removes the endpoint from the hash table with hlistdelinitrcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnetrxhandler -> rmnetmapingresshandler) may still hold a reference to the endpoint and dereference ep->egressdev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egressdev pointer.

BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: pocwrite Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnetvndrxfixup (rmnetvnd.c:27) Call Trace: <TASK> rmnetmapingresshandler (rmnethandlers.c:48 rmnethandlers.c:101) rmnetrxhandler (rmnethandlers.c:129 rmnethandlers.c:235) netifreceiveskbcore.constprop.0 (net/core/dev.c:6096) netifreceiveskbonecore (net/core/dev.c:6208) netifreceiveskb (net/core/dev.c:6467) tungetuser (drivers/net/tun.c:1955) tunchrwriteiter (drivers/net/tun.c:2003) vfswrite (fs/readwrite.c:688) ksyswrite (fs/readwrite.c:740) </TASK>

Add an rcuhead field to struct rmnetendpoint and replace kfree() with kfreercu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnetvnddellink() call and inline only the nrrmnetdevs decrement, since rmnetvnddellink() would set ep->egressdev to NULL during the grace period, creating a data race with lockless readers.

In the Linux kernel, the following vulnerability has been resolved:

iommu/amd: Remove latent out-of-bounds access in IOMMU debugfs

In iommummiowrite() and iommucapabilitywrite(), the variables dbgmmiooffset and dbgcapoffset are declared as int. However, they are populated using kstrtou32fromuser(). If a user provides a sufficiently large value, it can become a negative integer.

Prior to this patch, the AMD IOMMU debugfs implementation was already protected by different mechanisms.

1. #define OFSINSZ 8 ensures the user string <= 8 bytes, so e.g. 0xffffffff isn't a valid input.

if (cnt > OFSINSZ) return -EINVAL;

2. Implicit type promotion in iommummiowrite(), dbgmmiooffset is int and iommu->mmiophysend is u64

if (dbgmmiooffset > iommu->mmiophysend - sizeof(u64)) return -EINVAL;

3. The show handlers would currently catch the negative number and refuse to perform the read.

Replace kstrtou32fromuser() with kstrtos32fromuser() to parse the input, and check for negative values to explicitly prevent out-of-bounds memory accesses directly in iommummiowrite() and iommucapabilitywrite().

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: bnep: Fix UAF read of dev->name

bnepaddconnection() needs to keep holding the bnepsessionsem while reading dev->name (just like bnepgetconnlist() does); otherwise the bnepsession() thread can concurrently free the netdevice, which can for example be triggered by a concurrent bnepdelconnection().

(This UAF is fairly uninteresting from a security perspective; calling bnepaddconnection() requires passing a capable(CAPNETADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mld: stop TX during firmware restart

When iwlwifi firmware crashes (e.g., NMIINTERRUPTUNKNOWN on Intel BE201/Wi-Fi 7), iwlmldnicerror() sets mld->fwstatus.inhwrestart to true. However, iwlmldtxfromtxq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer.

Since the firmware is dead, iwltranstx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation.

The RX path already has this guard (iwlmldrxmpdu checks inhwrestart at rx.c:1906), and so does the TXQ allocation worker (iwlmldaddtxqswk at tx.c:156). Add the same guard to iwlmldtxfromtxq() to stop all TX during firmware restart.

Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwlmldtxfromtxq() via iwlmldaddtxqlist(), or when new upper-layer traffic invokes waketxqueue.

Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic.

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: fix driver-set TX rates on old devices

On old devices such as 7265D, rates are still encoded in version 1 format, which doesn't use the CCK/OFDM rate index (0-3/0-7) but rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.)

While introducing v3 rates, I changed the driver from internally handling v1 rates and converting to v2, to internally handling v3 and converting to v1 or v2 according to the firmware. I accordingly changed the code in iwlmvmmac80211idxtohwrate() to no longer have different values for different APIs. This was correct.

However, I later reverted this part of the change, because it was reported that I had broken beacon rates, causing a FW assert/crash. This caused TXCMD rates to be set incorrectly, potentially causing a warning when reported back from the device as having been used.

Fix this (hopefully correctly now) by handling beacon rates in the TXCMD that's embedded in the beacon template command separately. Restore iwlmvmmac80211idxtohwrate() to return only the rate index, not PLCP value, fixing the real TXCMD.

In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Disable AVIC IPI virtualization on Hygon Family 18h (erratum #1235)

Hygon Family 18h CPUs are derived from AMD Family 17h (Zen1) silicon and share the same erratum #1235: hardware may read a stale IsRunning=1 bit during ICR write emulation and silently fail to generate an AVICIPIFAILURETARGETNOTRUNNING VM-Exit on the sending vCPU.

The absence of the VM-Exit causes KVM to miss the required wakeup of blocking target vCPUs, leading to hung vCPUs and unbounded delays in guest execution.

Extend the existing AMD Family 17h erratum #1235 workaround to also cover Hygon Family 18h. With IPI virtualization disabled, KVM never sets IsRunning=1 in the Physical ID table, so every non-self IPI generates a VM-Exit and is correctly emulated.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix iommumapsgtable() return value check and avoid WARN

Commit "iommu: return full error code from iommumapsgatomic" changed iommumapsgtable() to return an ssizet and negative values in error cases, rather than a sizet and a zero.

Store the return value in the appropriate type and in case of error, return it rather than WARNing.

Patchwork: https://patchwork.freedesktop.org/patch/719685/

In the Linux kernel, the following vulnerability has been resolved:

iommu: Handle unmap error when iommudebug is enabled

Sashiko noticed a latent bug where the map error flow called iommuunmap() which calls iommudebugunmapbegin()/iommudebugunmapend() however since this is an error path the map flow never actually established the original iommudebugmap() it will malfunction.

Lift the unmap error handling into iommumapnosync() and reorder it so the tracemap()/iommudebugmap() records the partial mapping and then immediately unmaps it. This avoid creating the unbalanced tracking and provides saner tracing instead of a unmap unmatched to any map.

In the Linux kernel, the following vulnerability has been resolved:

iommupt: Check for missing PAGESIZE in the pgsizebitmap

Sashiko pointed out that the driver could drop PAGESIZE from the pgsizebitmap. That is technically allowed but nothing does it, and such an iommudomain would not be used with the DMA API today.

Still, it is against the design and it is trivial to fix up. Lift the PTWARNON to the if branch and just skip the fast path.

In the Linux kernel, the following vulnerability has been resolved:

pdscore: fix error handling in pdscdevcmdwait

Fix two cases where pdscdevcmdwait() returns stale success from the completion register instead of an error:

1. FW crash: If firmware stops running, the wait loop breaks early with running=false. The condition "if ((!done || timeout) && running)" is false, so error handling is bypassed and stale status is returned. Check !running first and return -ENXIO.

2. Timeout: If a command times out, err is set to -ETIMEDOUT but then overwritten by pdscerrtoerrno(status) which reads stale status. Return -ETIMEDOUT immediately after cleaning up.

Both errors now propagate to pdscdevcmdlocked() which queues healthwork for recovery.

In the Linux kernel, the following vulnerability has been resolved:

wifi: wilc1000: fix dmabuffer leak on bus acquire failure

wilcwlanfirmwaredownload() allocates dmabuffer with kmalloc() at the top of the function and uses a 'fail:' label to free it via kfree(dmabuffer) on error.

All later error paths correctly use 'goto fail' to route through this cleanup. However, the early failure path after the first acquirebus() call uses a bare 'return ret;', which leaks dmabuffer whenever the bus acquire fails.

Replace the early return with goto fail so the existing cleanup path runs.

Found via a custom Coccinelle semantic patch hunting for kmalloc'd locals leaked on early-return error paths in driver firmware-download code.

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix null pointer dereference in procshowfiles()

When a SMB2 client opens a file with a durable v2 handle and then issues SMB2 SESSIONLOGOFF, sessionfdcheck() clears fp->tcon = NULL on the reconnectable file pointer but leaves the fp registered in globalft.idr until the durable scavenger fires (up to fp->durabletimeout seconds later).

During that window any read of /proc/fs/ksmbd/files (mode 0400) panics the kernel because procshowfiles() walks globalft.idr and unconditionally dereferences fp->tcon->id with no NULL guard.

Reproducer requires only a successful SMB2 SESSIONSETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:procshowfiles+0x118/0x740 Call Trace: procshowfiles+0x118/0x740 seqreaditer+0x4ef/0xe10 procregreaditer+0x1b7/0x280 ...

Guard the dereference. A durable-disconnected fp legitimately has no tcon; report its tree id as 0 rather than oopsing.