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:

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:

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:

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.

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

ocfs2: fix out-of-bounds write in ocfs2writeendinline

KASAN reports a use-after-free write of 4086 bytes in ocfs2writeendinline, called from ocfs2writeendnolock during a copyfilerange splice fallback on a corrupted ocfs2 filesystem mounted on a loop device. The actual bug is an out-of-bounds write past the inode block buffer, not a true use-after-free. The write overflows into an adjacent freed page, which KASAN reports as UAF.

The root cause is that ocfs2trytowriteinlinedata trusts the on-disk idcount field to determine whether a write fits in inline data. On a corrupted filesystem, idcount can exceed the physical maximum inline data capacity, causing writes to overflow the inode block buffer.

Call trace (crash path):

vfscopyfilerange (fs/readwrite.c:1634) dosplicedirect splicedirecttoactor iterfilesplicewrite ocfs2filewriteiter genericperformwrite ocfs2writeend ocfs2writeendnolock (fs/ocfs2/aops.c:1949) ocfs2writeendinline (fs/ocfs2/aops.c:1915) memcpyfromfolio <-- KASAN: write OOB

So add idcount upper bound check in ocfs2validateinodeblock() to alongside the existing isize check to fix it.

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

eventpoll: defer struct eventpoll free to RCU grace period

In certain situations, epfree() in eventpoll.c will kfree the epi->ep eventpoll struct while it still being used by another concurrent thread. Defer the kfree() to an RCU callback to prevent UAF.

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

reset: gpio: fix double free in resetaddgpioauxdevice() error path

When auxiliarydeviceadd() fails, resetaddgpioauxdevice() calls auxiliarydeviceuninit(adev).

The device release callback resetgpioauxdevicerelease() frees adev, but the current error path then calls kfree(adev) again, causing a double free.

Keep kfree(adev) for the auxiliarydeviceinit() failure path, but avoid freeing adev after auxiliarydeviceuninit().

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

wifi: virtwifi: remove SETNETDEVDEV to avoid use-after-free

Currently we execute SETNETDEVDEV(dev, &priv->lowerdev->dev) for the virtwifi net devices. However, unregistering a virtwifi device in netdevruntodo() can happen together with the device referenced by SETNETDEVDEV().

It can result in use-after-free during the ethtool operations performed on a virtwifi device that is currently being unregistered. Such a net device can have the dev.parent field pointing to the freed memory, but ethnlopsbegin() calls pmruntimegetsync(dev->dev.parent).

Let's remove SETNETDEVDEV for virtwifi to avoid bugs like this:

================================================================== BUG: KASAN: slab-use-after-free in pmruntimeresume+0xe2/0xf0 Read of size 2 at addr ffff88810cfc46f8 by task pm/606

Call Trace: <TASK> dumpstacklvl+0x4d/0x70 printreport+0x170/0x4f3 ? pfxrawspinlockirqsave+0x10/0x10 kasanreport+0xda/0x110 ? pmruntimeresume+0xe2/0xf0 ? pmruntimeresume+0xe2/0xf0 pmruntimeresume+0xe2/0xf0 ethnlopsbegin+0x49/0x270 ethnlsetfeatures+0x23c/0xab0 ? pfxethnlsetfeatures+0x10/0x10 ? kvmschedclockread+0x11/0x20 ? localclocknoinstr+0xf/0xf0 ? localclock+0x10/0x30 ? kasansavetrack+0x25/0x60 ? kasankmalloc+0x7f/0x90 ? genlfamilyrcvmsgattrsparse.isra.0+0x150/0x2c0 genlfamilyrcvmsgdoit+0x1e7/0x2c0 ? pfxgenlfamilyrcvmsgdoit+0x10/0x10 ? pfxcredhascapability.isra.0+0x10/0x10 ? stacktracesave+0x8e/0xc0 genlrcvmsg+0x411/0x660 ? pfxgenlrcvmsg+0x10/0x10 ? pfxethnlsetfeatures+0x10/0x10 netlinkrcvskb+0x121/0x380 ? pfxgenlrcvmsg+0x10/0x10 ? pfxnetlinkrcvskb+0x10/0x10 ? pfxdownread+0x10/0x10 genlrcv+0x23/0x30 netlinkunicast+0x60f/0x830 ? pfxnetlinkunicast+0x10/0x10 ? pfxallocskb+0x10/0x10 netlinksendmsg+0x6ea/0xbc0 ? pfxnetlinksendmsg+0x10/0x10 ? futexqueue+0x10b/0x1f0 syssendmsg+0x7a2/0x950 ? copymsghdrfromuser+0x26b/0x430 ? pfxsyssendmsg+0x10/0x10 ? pfxcopymsghdrfromuser+0x10/0x10 syssendmsg+0xf8/0x180 ? pfxsyssendmsg+0x10/0x10 ? pfxfutexwait+0x10/0x10 ? fdget+0x2e4/0x4a0 syssendmsg+0x11f/0x1c0 ? pfxsyssendmsg+0x10/0x10 dosyscall64+0xe2/0x570 ? excpagefault+0x66/0xb0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

This fix may be combined with another one in the ethtool subsystem: https://lore.kernel.org/all/20260322075917.254874-1-alex.popov@linux.com/T/#u

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

firmware: thead: Fix buffer overflow and use standard endian macros

Addresses two issues in the TH1520 AON firmware protocol driver:

1. Fix a potential buffer overflow where the code used unsafe pointer arithmetic to access the 'mode' field through the 'resource' pointer with an offset. This was flagged by Smatch static checker as: "buffer overflow 'data' 2 <= 3"

2. Replace custom RPCSETBE and RPCGETBE macros with standard kernel endianness conversion macros (cputobe16, etc.) for better portability and maintainability.

The functionality was re-tested with the GPU power-up sequence, confirming the GPU powers up correctly and the driver probes successfully.

[ 12.702370] powervr ffef400000.gpu: [drm] loaded firmware powervr/rogue36.52.104.182v1.fw [ 12.711043] powervr ffef400000.gpu: [drm] FW version v1.0 (build 6645434 OS) [ 12.719787] [drm] Initialized powervr 1.0.0 for ffef400000.gpu on minor 0

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

rxrpc: only handle RESPONSE during service challenge

Only process RESPONSE packets while the service connection is still in RXRPCCONNSERVICECHALLENGING. Check that state under statelock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test.

afunix: read UNIXDIAGVFS data under unixstatelock

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

btrfs: fix incorrect return value after changing leaf in lookupextentdataref()

After commit 1618aa3c2e01 ("btrfs: simplify return variables in lookupextentdataref()"), the err and ret variables were merged into a single ret variable. However, when btrfsnextleaf() returns 0 (success), ret is overwritten from -ENOENT to 0. If the first key in the next leaf does not match (different objectid or type), the function returns 0 instead of -ENOENT, making the caller believe the lookup succeeded when it did not. This can lead to operations on the wrong extent tree item, potentially causing extent tree corruption.

Fix this by returning -ENOENT directly when the key does not match, instead of relying on the ret variable.

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

Input: uinput - fix circular locking dependency with ff-core

A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller):

ff->mutex -> udev->mutex -> inputmutex -> dev->mutex -> ff->mutex

The cycle is caused by four lock acquisition paths:

1. ff upload: inputffupload() holds ff->mutex and calls uinputdevuploadeffect() -> uinputrequestsubmit() -> uinputrequestsend(), which acquires udev->mutex.

2. device create: uinputioctlhandler() holds udev->mutex and calls uinputcreatedevice() -> inputregisterdevice(), which acquires inputmutex.

3. device register: inputregisterdevice() holds inputmutex and calls kbdconnect() -> inputregisterhandle(), which acquires dev->mutex.

4. evdev release: evdevrelease() calls inputflushdevice() under dev->mutex, which calls inputffflush() acquiring ff->mutex.

Fix this by introducing a new statelock spinlock to protect udev->state and udev->dev access in uinputrequestsend() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinputdevevent() -- both operations are safe under a spinlock (ktimegetts64() and wakeupinterruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes.

To keep state transitions visible to uinputrequestsend(), protect writes to udev->state in uinputcreatedevice() and uinputdestroydevice() with the same statelock spinlock.

Additionally, move initcompletion(&request->done) from uinputrequestsend() to uinputrequestsubmit() before uinputrequestreserveslot(). Once the slot is allocated, uinputflushrequests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible.

Lock ordering after the fix:

ff->mutex -> statelock (spinlock, leaf) udev->mutex -> statelock (spinlock, leaf) udev->mutex -> inputmutex -> dev->mutex -> ff->mutex (no back-edge)

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

netfilter: nftct: fix use-after-free in timeout object destroy

nftcttimeoutobjdestroy() frees the timeout object with kfree() immediately after nfctuntimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcudereference() in nfcttimeoutdata().

Add an rcuhead to struct nfcttimeout and use kfreercu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlinkcttimeout.c.

KASAN report: BUG: KASAN: slab-use-after-free in nfconntracktcppacket+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80

Call Trace: nfconntracktcppacket+0x1381/0x29d0 nfconntrackin+0x612/0x8b0 nfhookslow+0x70/0x100 iplocalout+0x1b2/0x210 tcpsendmsglocked+0x722/0x1580 syssendto+0x2d8/0x320

Allocated by task 75: nftcttimeoutobjinit+0xf6/0x290 nftobjinit+0x107/0x1b0 nftablesnewobj+0x680/0x9c0 nfnetlinkrcvbatch+0xc29/0xe00

Freed by task 26: nftobjdestroy+0x3f/0xa0 nftablestransdestroywork+0x51c/0x5c0 processonework+0x2c4/0x5a0

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

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NFHOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NFSTOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.