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

cifs: Fix busy dentry used after unmounting

Since commit 340cea84f691c ("cifs: open files should not hold ref on superblock"), cifs file only holds the dentry refcnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in genericshutdownsuper: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs]

The detailed processs is: process A process B kworker fd = open(PATH) vfsopen file->fpath = path // dentry->dlockref.count = 1 cifsopen cifsnewfileinfo cfile->dentry = dget(dentry) // dentry->dlockref.count = 2 close(fd) fput cifsclose queuedelayedwork(deferredclosewq, cfile->deferred) dput(dentry) // dentry->dlockref.count = 1 smb2deferredworkclose cifsFileInfoput listdel(&cifsfile->flist) umount cleanupmnt deactivatesuper cifskillsb cifsclosealldeferredfilessb cifsclosealldeferredfiles // cannot find cfile, skip cifsFileInfoput killanonsuper genericshutdownsuper shrinkdcacheforumount umountcheck WARN ! // dentry->dlockref.count = 1 cifsFileInfoputfinal dput(cifsfile->dentry) // dentry->dlockref.count = 0

Fix it by flushing 'deferredclosewq' before calling killanonsuper.

Fetch a reproducer in https://bugzilla.kernel.org/showbug.cgi?id=221548.

ALSA: PCM: Fix wait queue list corruption in sndpcmdrain() on linked streams

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

usb: class: cdc-wdm: fix reordering issue in read code path

Quoting the bug report:

Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdmread() can see the new length and call copytouser() on uninitialized memory. This also violates LKMM data race rules [1].

Fix it by using WRITEONCE and memory barriers.

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

usb: renesasusbhs: fix use-after-free in ISR during device removal

In usbhsremove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhsinterrupt) is still registered. If an interrupt fires after usbhspiperemove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free.

Fix this by calling devmfreeirq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhspiperemove() is called.

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

arm64: dts: qcom: monaco: Reserve full Gunyah metadata region

We observe spurious "Synchronous External Abort" exceptions (ESR=0x96000010) and kernel crashes on Monaco-based platforms. These faults are caused by the kernel inadvertently accessing hypervisor-owned memory that is not properly marked as reserved.

From boot log, The Qualcomm hypervisor reports the memory range at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned: qheehypassignremovememory: 0x91a80000/0x80000 -> ret 0

However, the EFI memory map provided by firmware only reserves the subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion (0x91a88000–0x91afffff) is incorrectly reported as conventional memory (from efi debug): efi: 0x000091a40000-0x000091a87fff [Reserved...] efi: 0x000091a88000-0x0000938fffff [Conventional...]

As a result, the allocator may hand out PFNs inside the hypervisor owned region, causing fatal aborts when the kernel accesses those addresses.

Add a reserved-memory carveout for the Gunyah hypervisor metadata at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not map or allocate from this area.

For the record: Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC) UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1

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

net: ipa: fix event ring index not programmed for IPA v5.0+

For IPA v5.0+, the event ring index field moved from CHCCNTXT0 to CHCCNTXT1. The v5.0 register definition intended to define this field in the CHCCNTXT1 fmask array but used the old identifier of ERINDEX instead of CHERINDEX.

Without a valid event ring, GSI channels could never signal transfer completions. This caused gsichanneltransquiesce() to block forever in waitforcompletion().

At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.

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

ipv6: prevent possible UaF in addrconfpermanentaddr()

The mentioned helper try to warn the user about an exceptional condition, but the message is delivered too late, accessing the ipv6 after its possible deletion.

Reorder the statement to avoid the possible UaF; while at it, place the warning outside the idev->lock as it needs no protection.

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

lib/crypto: chacha: Zeroize permutedstate before it leaves scope

Since the ChaCha permutation is invertible, the local variable 'permutedstate' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done.

While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG.

Thus, explicitly zeroize 'permutedstate' before it goes out of scope.

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

Bluetooth: SMP: force responder MITM requirements before building the pairing response

smpcmdpairingreq() currently builds the pairing response from the initiator authreq before enforcing the local BTSECURITYHIGH requirement. If the initiator omits SMPAUTHMITM, the response can also omit it even though the local side still requires MITM.

tkrequest() then sees an auth value without SMPAUTHMITM and may select JUSTCFM, making method selection inconsistent with the pairing policy the responder already enforces.

When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMPAUTHMITM in the response in both rsp.authreq and auth. This keeps the responder auth bits and later method selection aligned.

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

thermal: core: Fix thermal zone device registration error path

If thermalzonedeviceregisterwithtrips() fails after registering a thermal zone device, it needs to wait for the tz->removal completion like thermalzonedeviceunregister(), in case user space has managed to take a reference to the thermal zone device's kobject, in which case thermalrelease() may not be called by the error path itself and tz may be freed prematurely.

Add the missing waitforcompletion() call to the thermal zone device registration error path.

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

crypto: caam - fix overflow on long hmac keys

When a key longer than block size is supplied, it is copied and then hashed into the real key. The memory allocated for the copy needs to be rounded to DMA cache alignment, as otherwise the hashed key may corrupt neighbouring memory.

The copying is performed using kmemdup, however this leads to an overflow: reading more bytes (alignedlen - keylen) from the keylen source buffer. Fix this by replacing kmemdup with kmalloc, followed by memcpy.

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

netfilter: flowtable: strictly check for maximum number of actions

The maximum number of flowtable hardware offload actions in IPv6 is:

ethernet mangling (4 payload actions, 2 for each ethernet address) SNAT (4 payload actions) DNAT (4 payload actions) Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. Redirect (1 action)

Which makes 17, while the maximum is 16. But actct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions.

Update flowactionentrynext() calls to check for the maximum number of supported actions.

While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.

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

cpufreq: governor: fix double free in cpufreqdbsgovernorinit() error path

When kobjectinitandadd() fails, cpufreqdbsgovernorinit() calls kobjectput(&dbsdata->attrset.kobj).

The kobject release callback cpufreqdbsdatarelease() calls gov->exit(dbsdata) and kfree(dbsdata), but the current error path then calls gov->exit(dbsdata) and kfree(dbsdata) again, causing a double free.

Keep the direct kfree(dbsdata) for the gov->init() failure path, but after kobjectinitandadd() has been called, let kobjectput() handle the cleanup through cpufreqdbsdatarelease().

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

USB: dummy-hcd: Fix interrupt synchronization error

This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), which added an emulated "interrupts enabled" flag together with code emulating synchronizeirq() (it waits until all current handler callbacks have returned).

But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb: gadget: dummyhcd: fix gpf in gadgetsetup") tried to fix this by moving the synchronizeirq() emulation code from dummystop() to dummypullup(), which runs before the unbind callback.

There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummypullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Add udcasynccallbacks gadget op") and 04145a03db9d ("USB: UDC: Implement udcasynccallbacks in dummy-hcd") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled.

That brings us to the current state of things, which is still wrong because the emulated synchronizeirq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronizeirq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound.

To fix this, we have to move the synchronizeirq() emulation code yet again, to the dummyudcasynccallbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.

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

Bluetooth: hcisync: Fix UAF in lereadfeaturescomplete

This fixes the following backtrace caused by hciconn being freed before lereadfeaturescomplete but after hcilereadremotefeaturessync so hciconndel -> hcicmdsyncdequeue is not able to prevent it:

================================================================== BUG: KASAN: slab-use-after-free in instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] BUG: KASAN: slab-use-after-free in atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] BUG: KASAN: slab-use-after-free in hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] BUG: KASAN: slab-use-after-free in lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 Write of size 4 at addr ffff8880796b0010 by task kworker/u9:0/52

CPU: 0 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:194 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:200 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 hcicmdsyncwork+0x1ff/0x430 net/bluetooth/hcisync.c:334 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK>

Allocated by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:400 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:417 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] hciconnadd+0xf8/0x1c70 net/bluetooth/hciconn.c:963 hciconnaddunset+0x76/0x100 net/bluetooth/hciconn.c:1084 leconncompleteevt+0x639/0x1f20 net/bluetooth/hcievent.c:5714 hcileenhconncompleteevt+0x23d/0x380 net/bluetooth/hcievent.c:5861 hcilemetaevt+0x357/0x5e0 net/bluetooth/hcievent.c:7408 hcieventfunc net/bluetooth/hcievent.c:7716 [inline] hcieventpacket+0x685/0x11c0 net/bluetooth/hcievent.c:7773 hcirxwork+0x2c9/0xeb0 net/bluetooth/hcicore.c:4076 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

Freed by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:587 kasansavefreeinfo mm/kasan/kasan.h:406 [inline] poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfree mm/slub.c:6663 [inline] kfree+0x2f8/0x6e0 mm/slub.c:6871 devicerelease+0xa4/0x240 drivers/base/core.c:2565 kobjectcleanup lib/kobject.c:689 [inline] kobjectrelease lib/kobject.c:720 [inline] krefput include/linux/kref.h:65 [inline] kobjectput+0x1e7/0x590 lib/kobject. ---truncated---

bpf: Properly mark live registers for indirect jumps

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

RDMA/irdma: Fix double free related to reregusermr

If IBMRREREGTRANS is set during reregusermr, the umem will be released and a new one will be allocated in irdmareregmrtrans. If any step of irdmareregmrtrans fails after the new umem is allocated, it releases the umem, but does not set iwmr->region to NULL. The problem is that this failure is propagated to the user, who will then call ibvderegmr (as they should). Then, the deregmr path will see a non-NULL umem and attempt to call ibumemrelease again.

Fix this by setting iwmr->region to NULL after ibumemrelease.

Fixed: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region")

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

netfilter: ctnetlink: ensure safe access to master conntrack

Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid.

To access exp->master safely:

- Grab the nfconntrackexpectlock, this gets serialized with cleanfromlists() which also holds this lock when the master conntrack goes away.

- Hold reference on master conntrack via nfconntrackfindget(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.

This patch goes for extending the nfconntrackexpectlock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section.

The add expectation command already holds a reference to the master conntrack from ctnetlinkcreateexpect().

However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nfctexpectiteratenet() calls already grabs the spinlock while iterating over the expectation table, which is correct.

The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFPKERNEL.

For the expectation events, the IPEXPDESTROY event is already delivered under the spinlock, just move the delivery of IPEXPNEW under the spinlock too because the master conntrack event cache is reached through exp->master.

While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.

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

wifi: wl1251: validate packet IDs before indexing txframes

wl1251txpacketcb() uses the firmware completion ID directly to index the fixed 16-entry wl->txframes[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it.

Reject completion IDs that fall outside wl->txframes[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.

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

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

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

HID: roccat: fix use-after-free in roccatreportevent

roccatreportevent() iterates over the device->readers list without holding the readerslock. This allows a concurrent roccatrelease() to remove and free a reader while it's still being accessed, leading to a use-after-free.

Protect the readers list traversal with the readerslock mutex.

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

wifi: brcmfmac: validate bsscfg indices in IF events

brcmffwehhandleifevent() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check.

Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array.

[add missing wifi prefix]

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

cachefiles: fix incorrect dentry refcount in cachefilescull()

The patch mentioned below changed cachefilesburyobject() to expect 2 references to the 'rep' dentry. Three of the callers were changed to use startremovingdentry() which takes an extra reference so in those cases the call gets the expected references.

However there is another call to cachefilesburyobject() in cachefilescull() which did not need to be changed to use startremovingdentry() and so was not properly considered. It still passed the dentry with just one reference so the net result is that a reference is lost.

To meet the expectations of cachefilesburyobject(), cachefilescull() must take an extra reference before the call. It will be dropped by cachefilesburyobject().

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

ipv6: ioam: fix potential NULL dereferences in ioam6filltracedata()

We need to check in6devget() for possible NULL value, as suggested by Yiming Qian.

Also add skbdstdevrcu() instead of skbdstdev(), and two missing READONCE().

Note that @dev can't be NULL.

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

ipv4: icmp: fix null-ptr-deref in icmpbuildprobe()

ipv6stub->ipv6devfind() may return ERRPTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIGIPV6=m and not loaded), and passing this error pointer to devhold() will cause a kernel crash with null-ptr-deref.

Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".

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

PCI: hv: Fix double idafree in hvpciprobe error path

If hvpciprobe() fails after storing the domain number in hbus->bridge->domainnr, there is a call to free this domainnr via pcibusreleaseemuldomainnr(), however, during cleanup, the bridge release callback pcireleasehostbridgedev() also frees the domainnr causing idafree to be called on same ID twice and triggering following warning:

idafree called for id=28971 which is not allocated. WARNING: lib/idr.c:594 at idafree+0xdf/0x160, CPU#0: kworker/0:2/198 Call Trace: pcibusreleaseemuldomainnr+0x17/0x20 pcireleasehostbridgedev+0x4b/0x60 devicerelease+0x3b/0xa0 kobjectput+0x8e/0x220 devmpciallochostbridgerelease+0xe/0x20 devresreleaseall+0x9a/0xd0 deviceunbindcleanup+0x12/0xa0 reallyprobe+0x1c5/0x3f0 vmbusaddchannelwork+0x135/0x1a0

Fix this by letting pci core handle the free domainnr and remove the explicit free called in pci-hyperv driver.

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

xsk: tighten UMEM headroom validation to account for tailroom and min frame

The current headroom validation in xdpumemreg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. Furthermore if multi-buffer would come to play then skbsharedinfo stored at the end of XSK frame would be corrupted.

HW typically works with 128-aligned sizes so let us provide this value as bare minimum.

Multi-buffer setting is known later in the configuration process so besides accounting for 128 bytes, let us also take care of tailroom space upfront.

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

xfrm: Wait for RCU readers during policy netns exit

xfrmpolicyfini() frees the policybydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first.

The policybydst tables are published via rcuassignpointer() and are looked up through rcudereferencecheck(), so netns teardown must also wait for an RCU grace period before freeing the table memory.

Fix this by adding synchronizercu() before freeing the policy hash tables.

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

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

ocfs2: validate inline data isize during inode read

When reading an inode from disk, ocfs2validateinodeblock() performs various sanity checks but does not validate the size of inline data. If the filesystem is corrupted, an inode's isize can exceed the actual inline data capacity (idcount).

This causes ocfs2dirforeachblkid() to iterate beyond the inline data buffer, triggering a use-after-free when accessing directory entries from freed memory.

In the syzbot report: - isize was 1099511627576 bytes (~1TB) - Actual inline data capacity (idcount) is typically <256 bytes - A garbage reclen (54648) caused ctx->pos to jump out of bounds - This triggered a UAF in ocfs2checkdirentry()

Fix by adding a validation check in ocfs2validateinodeblock() to ensure inodes with inline data have isize <= idcount. This catches the corruption early during inode read and prevents all downstream code from operating on invalid data.