audit: Fix data races of skbqueuelen() readers on auditqueue

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

tracing: Prevent out-of-bounds read in glob matching

String event fields are not necessarily NUL-terminated, so the filter predicate functions (filterpredstring(), filterpredstrloc() and filterpredstrrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it.

regexmatchglob() was the exception: it ignored the length and called globmatch(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in globmatch(), reached via regexmatchglob() and filtermatchpreds() from the xfslookup tracepoint.

Add a length-bounded globmatchlen() and use it from regexmatchglob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so globmatch() keeps its behaviour.

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

fpga: region: fix use-after-free in childregionswithfirmware()

Move ofnodeput(childregion) after the error print to avoid accessing freed memory when prerr() references childregion.

[ Yilun: Fix the Fixes tag ]

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

libceph: Fix potential out-of-bounds access in cephxdecrypt()

In cephxdecrypt(), a part of the buffer p is interpreted as a cephxencryptheader, and the magic field of this struct is accessed. This happens without any guarantee that the buffer is large enough to hold this struct. The function parameter ciphertextlen represents the length of the ciphertext to decrypt and is guaranteed to be at most the remaining size of the allocated buffer p. However, this value is not necessarily greater than sizeof(cephxencryptheader). E.g., a message frame of type FRAMETAGAUTHREPLYMORE, that is just as long to hold the ciphertext at its end with a ciphertextlen of 8 or less, can trigger an out-of-bounds memory access when accessing hdr->magic.

This patch fixes the issue by adding a check to ensure that the decrypted plaintext in the buffer is large enough to represent at least the cephxencryptheader.

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

apparmor: fix rlimit for posix cpu timers

Posix cpu timers requires an additional step beyond setting the rlimit. Refactor the code so its clear when what code is setting the limit and conditionally update the posix cpu timers when appropriate.

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

nvmet: avoid recursive nvmet-wq flush in nvmetctrlfree

nvmettcpreleasequeuework() runs on nvmet-wq and can drop the final controller reference through nvmetcqput(). If that triggers nvmetctrlfree(), the teardown path flushes ctrl->asynceventwork on the same nvmet-wq.

Call chain:

nvmettcpschedulereleasequeue() krefput(&queue->kref, nvmettcpreleasequeue) nvmettcpreleasequeue() queuework(nvmetwq, &queue->releasework) <--- nvmetwq processonework() nvmettcpreleasequeuework() nvmetcqput(&queue->nvmecq) nvmetcqdestroy() nvmetctrlput(cq->ctrl) nvmetctrlfree() flushwork(&ctrl->asynceventwork) <--- nvmetwq

Previously Scheduled by :- nvmetaddasyncevent queuework(nvmetwq, &ctrl->asynceventwork);

This trips lockdep with a possible recursive locking warning.

[ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55 [ 5223.061801] loop0: detected capacity change from 0 to 2097152 [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1 [ 5223.088368] nvmettcp: enabling port 0 (127.0.0.1:4420) [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349. [ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349 [ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery"

[ 5233.227718] ============================================ [ 5233.231283] WARNING: possible recursive locking detected [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N [ 5233.238434] -------------------------------------------- [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock: [ 5233.245429] ffff888111632548 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90 [ 5233.251438] but task is already holding lock: [ 5233.255254] ffff888111632548 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x5cc/0x6e0 [ 5233.261125] other info that might help us debug this: [ 5233.265333] Possible unsafe locking scenario:

[ 5233.269217] CPU0 [ 5233.270795] ---- [ 5233.272436] lock((wqcompletion)nvmet-wq); [ 5233.275241] lock((wqcompletion)nvmet-wq); [ 5233.278020] DEADLOCK

[ 5233.281793] May be due to missing lock nesting notation

[ 5233.286195] 3 locks held by kworker/u192:6/2413: [ 5233.289192] #0: ffff888111632548 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x5cc/0x6e0 [ 5233.294569] #1: ffffc9000e2a7e40 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x6e0 [ 5233.300128] #2: ffffffff82d7dc40 (rcureadlock){....}-{1:3}, at: flushwork+0x62/0x530 [ 5233.304290] stack backtrace: [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full) [ 5233.306524] Tainted: [O]=OOTMODULE, [N]=TEST [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 5233.306527] Workqueue: nvmet-wq nvmettcpreleasequeuework [nvmettcp] [ 5233.306532] Call Trace: [ 5233.306534] <TASK> [ 5233.306536] dumpstacklvl+0x73/0xb0 [ 5233.306552] printdeadlockbug+0x225/0x2f0 [ 5233.306556] lockacquire+0x13f0/0x2290 [ 5233.306563] lockacquire+0xd0/0x300 [ 5233.306565] ? touchwqlockdepmap+0x26/0x90 [ 5233.306571] ? flushwork+0x20b/0x530 [ 5233.306573] ? touchwqlockdepmap+0x26/0x90 [ 5233.306577] touchwqlockdepmap+0x3b/0x90 [ 5233.306580] ? touchwqlockdepmap+0x26/0x90 [ 52 ---truncated---

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

RDMA/vmwpvrdma: Fix double free on pvrdmaallocucontext() error path

Sashiko points out that pvrdmauarfree() is already called within pvrdmadeallocucontext(), so calling it before triggers a double free.

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

md/raid5: validate payload size before accessing journal metadata

r5crecoveryanalyzemetablock() and r5lrecoveryverifydatachecksumformb() iterate over payloads in a journal metadata block using on-disk payload size fields without validating them against the remaining space in the metadata block.

A corrupted journal contains payload sizes extending beyond the PAGESIZE boundary can cause out-of-bounds reads when accessing payload fields or computing offsets.

Add bounds validation for each payload type to ensure the full payload fits within metasize before processing.

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

media: mtk-mdp: Fix error handling in probe function

Add mtkmdpunregisterm2mdevice() on the error handling path to prevent resource leak.

Add check for the return value of vpugetplatdevice() to prevent null pointer dereference. And vpugetplatdevice() increases the reference count of the returned platform device. Add platformdeviceput() to prevent reference leak.

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

iio: gyro: mpu3050: Move iiodeviceregister() to correct location

iiodeviceregister() should be at the end of the probe function to prevent race conditions.

Place iiodeviceregister() at the end of the probe function and place iiodeviceunregister() accordingly.

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

spi: spi-fsl-lpspi: fix teardown order issue (UAF)

There is a teardown order issue in the driver. The SPI controller is registered using devmspiregistercontroller(), which delays unregistration of the SPI controller until after the fsllpspiremove() function returns.

As the fsllpspiremove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free:

| fsllpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsllpspidmatransfer+0x260/0x340 [spifsllpspi] | fsllpspitransferone+0x198/0x448 [spifsllpspi] | spitransferonemessage+0x49c/0x7c8 | spipumptransfermessage+0x120/0x420 | spisync+0x2c4/0x520 | spisync+0x34/0x60 | spidevmessage+0x20c/0x378 [spidev] | spidevioctl+0x398/0x750 [spidev] [...]

Switch from devmspiregistercontroller() to spiregistercontroller() in fsllpspiprobe() and add the corresponding spiunregistercontroller() in fsllpspiremove().

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

netfilter: nftables: unconditionally bump set->nelems before insertion

In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already.

To address this issue, add the element transaction even if set is full, but toggle the setfull flag to report -ENFILE so the abort path safely unwinds the set to its previous state.

As for element updates, decrement set->nelems to restore it.

A simpler fix is to call synchronizercu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.

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

wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmffwallocrequest()

This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITSPERTYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmfusbprobecb() or brcmfusbresetresume(), for example.

Found by a modified version of syzkaller.

UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usbhubwq hubevent Call Trace: dumpstacklvl+0x57/0x7d ubsanepilogue+0x5/0x40 ubsanhandleshiftoutofbounds.cold+0x53/0xdb ? lockchaincount+0x20/0x20 brcmffwallocrequest.cold+0x19/0x3ea ? brcmffwgetfirmwares+0x250/0x250 ? brcmfusbioctlrespwait+0x1a7/0x1f0 brcmfusbgetfwname+0x114/0x1a0 ? brcmfusbresetresume+0x120/0x120 ? number+0x6c4/0x9a0 brcmfcprocessclmblob+0x168/0x590 ? putdec+0x90/0x90 ? enableptrkeyworkfn+0x20/0x20 ? brcmfcommonpdremove+0x50/0x50 ? rcureadlockschedheld+0xa1/0xd0 brcmfcpreinitdcmds+0x673/0xc40 ? brcmfcsetjoinprefdefault+0x100/0x100 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockacquire+0x19d/0x4e0 ? findheldlock+0x2d/0x110 ? brcmfusbdeq+0x1cc/0x260 ? markheldlocks+0x9f/0xe0 ? lockdephardirqsonprepare+0x273/0x3e0 ? rawspinunlockirqrestore+0x47/0x50 ? tracehardirqson+0x1c/0x120 ? brcmfusbdeq+0x1a7/0x260 ? brcmfusbrxfillall+0x5a/0xf0 brcmfattach+0x246/0xd40 ? wiphynewnm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmfusbprobe+0x12de/0x1690 ? brcmfusbdevqinit.constprop.0+0x470/0x470 usbprobeinterface+0x25f/0x710 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 ? usbmatchid.part.0+0x88/0xc0 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? mutexunlockslowpath+0xe7/0x660 ? fwdevlinklinktosuppliers+0x550/0x550 usbsetconfiguration+0x984/0x1770 ? kernfscreatelink+0x175/0x230 usbgenericdriverprobe+0x69/0x90 usbprobedevice+0x9c/0x220 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? fwdevlinklinktosuppliers+0x550/0x550 usbnewdevice.cold+0x463/0xf66 ? hubdisconnect+0x400/0x400 ? rawspinunlockirq+0x24/0x30 hubevent+0x10d5/0x3330 ? hubportdebounce+0x280/0x280 ? lockacquire+0x1671/0x5790 ? wqcalcnodecpumask+0x170/0x2a0 ? lockrelease+0x640/0x640 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockdephardirqsonprepare+0x273/0x3e0 processonework+0x873/0x13e0 ? lockrelease+0x640/0x640 ? pwqdecnrinflight+0x320/0x320 ? rwlockbug.part.0+0x90/0x90 workerthread+0x8b/0xd10 ? kthreadparkme+0xd9/0x1d0 ? pr ---truncated---

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

media: si470x: Fix use-after-free in si470xintincallback()

syzbot reported use-after-free in si470xintincallback() [1]. This indicates that urb->context, which contains struct si470xdevice object, is freed when si470xintincallback() is called.

The cause of this issue is that si470xintincallback() is called for freed urb.

si470xusbdriverprobe() calls si470xstartusb(), which then calls usbsubmiturb() and si470xstart(). If si470xstartusb() fails, si470xusbdriverprobe() doesn't kill urb, but it just frees struct si470xdevice object, as depicted below:

si470xusbdriverprobe() ... si470xstartusb() ... usbsubmiturb() retval = si470xstart() return retval if (retval < 0) free struct si470xdevice object, but don't kill urb

This patch fixes this issue by killing urb when si470xstartusb() fails and urb is submitted. If si470xstartusb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470xdevice object.

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

binfmtmisc: fix shift-out-of-bounds in checkspecialflags

UBSAN reported a shift-out-of-bounds warning:

left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x8d/0xcf lib/dumpstack.c:106 ubsanepilogue+0xa/0x44 lib/ubsan.c:151 ubsanhandleshiftoutofbounds+0x1e7/0x208 lib/ubsan.c:322 checkspecialflags fs/binfmtmisc.c:241 [inline] createentry fs/binfmtmisc.c:456 [inline] bmregisterwrite+0x9d3/0xa20 fs/binfmtmisc.c:654 vfswrite+0x11e/0x580 fs/readwrite.c:582 ksyswrite+0xcf/0x120 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x34/0x80 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x4194e1

Since the type of Node's flags is unsigned long, we should define these macros with same type too.

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

dm cache: Fix UAF in destroy()

Dmcache also has the same UAF problem when dmresume() and dmdestroy() are concurrent.

Therefore, cancelling timer again in destroy().

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

nilfs2: fix shift-out-of-bounds/overflow in nilfssb2badoffset()

Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount time".

The first patch fixes a bug reported by syzbot, and the second one fixes the remaining bug of the same kind. Although they are triggered by the same super block data anomaly, I divided it into the above two because the details of the issues and how to fix it are different.

Both are required to eliminate the shift-out-of-bounds issues at mount time.

This patch (of 2):

If the block size exponent information written in an on-disk superblock is corrupted, nilfssb2badoffset helper function can trigger shift-out-of-bounds warning followed by a kernel panic (if paniconwarn is set):

shift exponent 38983 is too large for 64-bit type 'unsigned long long' Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:151 [inline] ubsanhandleshiftoutofbounds+0x33d/0x3b0 lib/ubsan.c:322 nilfssb2badoffset fs/nilfs2/thenilfs.c:449 [inline] nilfsloadsuperblock+0xdf5/0xe00 fs/nilfs2/thenilfs.c:523 initnilfs+0xb7/0x7d0 fs/nilfs2/thenilfs.c:577 nilfsfillsuper+0xb1/0x5d0 fs/nilfs2/super.c:1047 nilfsmount+0x613/0x9b0 fs/nilfs2/super.c:1317 ...

In addition, since nilfssb2badoffset() performs multiplication without considering the upper bound, the computation may overflow if the disk layout parameters are not normal.

This fixes these issues by inserting preliminary sanity checks for those parameters and by converting the comparison from one involving multiplication and left bit-shifting to one using division and right bit-shifting.

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

xhci: Remove device endpoints from bandwidth list when freeing the device

Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed.

If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller.

So check and delete endpoints that are still on the bandwidth list when freeing the virt device.

Solves a listdel corruption kernel crash when unbinding xhci-pci, caused by xhcimemcleanup() when it later tried to delete already freed endpoints from the bandwidth list.

This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)

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

drm/vmwgfx: Validate the box size for the snooped cursor

Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor.

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

drm/msm/hdmi: fix memory corruption with too many bridges

Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges.

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

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

kernfs: fix use-after-free in kernfsremove

Syzkaller managed to trigger concurrent calls to kernfsremovebynamens() for the same file resulting in a KASAN detected use-after-free. The race occurs when the root node is freed during kernfsdrain().

To prevent this acquire an additional reference for the root of the tree that is removed before calling kernfsremove().

Found by syzkaller with the following reproducer (slabnomerge is required):

syzmountimage$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0) r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0) close(r0) pipe2(&(0x7f0000000140)={0xffffffffffffffff, <r1=>0xffffffffffffffff}, 0x800) mount$9pfd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cacheloose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAYEXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@donthash}]}})

Sample report:

================================================================== BUG: KASAN: use-after-free in kernfstype include/linux/kernfs.h:335 [inline] BUG: KASAN: use-after-free in kernfsleftmostdescendant fs/kernfs/dir.c:1261 [inline] BUG: KASAN: use-after-free in kernfsremove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857

CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x6e/0x91 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:317 [inline] printreport.cold+0x5e/0x5e5 mm/kasan/report.c:433 kasanreport+0xa3/0x130 mm/kasan/report.c:495 kernfstype include/linux/kernfs.h:335 [inline] kernfsleftmostdescendant fs/kernfs/dir.c:1261 [inline] kernfsremove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 kernfsremove fs/kernfs/dir.c:1356 [inline] kernfsremovebynamens+0x108/0x190 fs/kernfs/dir.c:1589 sysfsslabadd+0x133/0x1e0 mm/slub.c:5943 kmemcachecreate+0x3e0/0x550 mm/slub.c:4899 createcache mm/slabcommon.c:229 [inline] kmemcachecreateusercopy+0x167/0x2a0 mm/slabcommon.c:335 p9clientcreate+0xd4d/0x1190 net/9p/client.c:993 v9fssessioninit+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fsmount+0xb9/0xbd0 fs/9p/vfssuper.c:126 legacygettree+0xf1/0x200 fs/fscontext.c:610 vfsgettree+0x85/0x2e0 fs/super.c:1530 donewmount fs/namespace.c:3040 [inline] pathmount+0x675/0x1d00 fs/namespace.c:3370 domount fs/namespace.c:3383 [inline] dosysmount fs/namespace.c:3591 [inline] sesysmount fs/namespace.c:3568 [inline] x64sysmount+0x282/0x300 fs/namespace.c:3568 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x38/0x90 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7f725f983aed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIGRAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000 R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000 </TASK>

Allocated by task 855: kasansavestack+0x1e/0x40 mm/kasan/common.c:38 kasansettrack mm/kasan/common.c:45 [inline] setallocinfo mm/kasan/common.c:437 [inline] kasanslaballoc+0x66/0x80 mm/kasan/common.c:470 kasanslaballoc include/linux/kasan.h:224 [inline] slabpostallochook mm/slab.h:7 ---truncated---

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

ACPICA: Fix use-after-free in acpiutcopyipackagetoipackage()

There is an use-after-free reported by KASAN:

BUG: KASAN: use-after-free in acpiutremovereference+0x3b/0x82 Read of size 1 at addr ffff888112afc460 by task modprobe/2111 CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), Call Trace: <TASK> kasanreport+0xae/0xe0 acpiutremovereference+0x3b/0x82 acpiutcopyiobjecttoiobject+0x3be/0x3d5 acpidsstoreobjecttolocal+0x15d/0x3a0 acpiexstore+0x78d/0x7fd acpiexopcode1A1T1R+0xbe4/0xf9b acpipsparseaml+0x217/0x8d5 ... </TASK>

The root cause of the problem is that the acpioperandobject is freed when acpiutwalkpackagetree() fails in acpiutcopyipackagetoipackage(), lead to repeated release in acpiutcopyiobjecttoiobject(). The problem was introduced by "8aa5e56eeb61" commit, this commit is to fix memory leak in acpiutcopyiobjecttoiobject(), repeatedly adding remove operation, lead to "acpioperandobject" used after free.

Fix it by removing acpiutremovereference() in acpiutcopyipackagetoipackage(). acpiutcopyipackagetoipackage() is called to copy an internal package object into another internal package object, when it fails, the memory of acpioperandobject should be freed by the caller.

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

Bluetooth: hcisysfs: Fix attempting to call deviceadd multiple times

deviceadd shall not be called multiple times as stated in its documentation:

'Do not call this routine or deviceregister() more than once for any device structure'

Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> listadd include/linux/list.h:69 [inline] listaddtail include/linux/list.h:102 [inline] kobjksetjoin lib/kobject.c:164 [inline] kobjectaddinternal+0x18f/0x8f0 lib/kobject.c:214 kobjectaddvarg lib/kobject.c:358 [inline] kobjectadd+0x150/0x1c0 lib/kobject.c:410 deviceadd+0x368/0x1e90 drivers/base/core.c:3452 hciconnaddsysfs+0x9b/0x1b0 net/bluetooth/hcisysfs.c:53 hcilecisestabilishedevt+0x57c/0xae0 net/bluetooth/hcievent.c:6799 hcilemetaevt+0x2b8/0x510 net/bluetooth/hcievent.c:7110 hcieventfunc net/bluetooth/hcievent.c:7440 [inline] hcieventpacket+0x63d/0xfd0 net/bluetooth/hcievent.c:7495 hcirxwork+0xae7/0x1230 net/bluetooth/hcicore.c:4007 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>

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

ACPICA: Fix error code path in acpidscallcontrolmethod()

A use-after-free in acpipsparseaml() after a failing invocaion of acpidscallcontrolmethod() is reported by KASAN [1] and code inspection reveals that nextwalkstate pushed to the thread by acpidscreatewalkstate() is freed on errors, but it is not popped from the thread beforehand. Thus acpidsgetcurrentwalkstate() called by acpipsparseaml() subsequently returns it as the new walk state which is incorrect.

To address this, make acpidscallcontrolmethod() call acpidspopwalkstate() to pop nextwalkstate from the thread before returning an error.

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

net/tunnel: wait until all skuserdata reader finish before releasing the sock

There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlansock vs from skuserdata. Then in later vxlanecndecapsulate(), vxlangetskfamily() we will got NULL pointer dereference. e.g.

#0 [ffffa25ec6978a38] machinekexec at ffffffff8c669757 #1 [ffffa25ec6978a90] crashkexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crashkexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oopsend at ffffffff8c627f2b #4 [ffffa25ec6978b80] pagefaultoops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] excpagefault at ffffffff8d109542 #6 [ffffa25ec6978c00] asmexcpagefault at ffffffff8d200b62 [exception RIP: vxlanecndecapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlanrcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udpqueuercvoneskb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udpunicastrcvskb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] udp4librcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ipprotocoldeliverrcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] iplocaldeliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] netifreceiveskbonecore at ffffffff8cecde9b #14 [ffffa25ec6978ec8] processbacklog at ffffffff8cece139 #15 [ffffa25ec6978f00] napipoll at ffffffff8ceced1a #16 [ffffa25ec6978f28] netrxaction at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] softirqentrytextstart at ffffffff8d4000ca #18 [ffffa25ec6978ff0] dosoftirq at ffffffff8c6fbdc3

Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh

Fix this by waiting for all skuserdata reader to finish before releasing the sock.

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

i2c: ismt: Fix an out-of-bounds bug in ismtaccess()

When the driver does not check the data from the user, the variable 'data->block[0]' may be very large to cause an out-of-bounds bug.

The following log can reveal it:

[ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20 [ 33.995978] ismtsmbus 0000:00:05.0: I2CSMBUSBLOCKDATA: WRITE [ 33.996475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismtaccess.cold+0x374/0x214b [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismtpoc/485 [ 33.999450] Call Trace: [ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismtaccess.cold+0x374/0x214b [ 34.003382] i2csmbusxfer+0x44f/0xfb0 [ 34.004007] i2csmbusxfer+0x10a/0x390 [ 34.004291] i2cdevioctlsmbus+0x2c8/0x710 [ 34.005196] i2cdevioctl+0x5ec/0x74c

Fix this bug by checking the size of 'data->block[0]' first.

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

Bluetooth: L2CAP: Fix user-after-free

This uses l2capchanholdunlesszero() after calling l2capgetchanblah() to prevent the following trace:

Bluetooth: l2capcore.c:static void l2capchandestroy(struct kref kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in mutexwaiterisfirst kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in mutexlockcommon kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in mutexlock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389

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

staging: vmeuser: Fix possible UAF in tsi148dmalistadd

Smatch report warning as follows:

drivers/staging/vmeuser/vmetsi148.c:1757 tsi148dmalistadd() warn: '&entry->list' not removed from list

In tsi148dmalistadd(), the error path "goto errdma" will not remove entry->list from list->entries, but entry will be freed, then list traversal may cause UAF.

Fix by removeing it from list->entries before free().

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

drm/meson: reorder driver deinit sequence to fix use-after-free bug

Unloading the driver triggers the following KASAN warning:

[ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in listdelentryvalid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695

[ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dumpbacktrace+0x1ec/0x280 [ +0.000013] showstack+0x24/0x80 [ +0.000008] dumpstacklvl+0x98/0xd4 [ +0.000011] printaddressdescription.constprop.0+0x80/0x520 [ +0.000011] printreport+0x128/0x260 [ +0.000007] kasanreport+0xb8/0xfc [ +0.000008] asanreportload8noabort+0x3c/0x50 [ +0.000010] listdelentryvalid+0xe0/0x1a0 [ +0.000009] drmatomicprivateobjfini+0x30/0x200 [drm] [ +0.000172] drmbridgedetach+0x94/0x260 [drm] [ +0.000145] drmencodercleanup+0xa4/0x290 [drm] [ +0.000144] drmmodeconfigcleanup+0x118/0x740 [drm] [ +0.000143] drmmodeconfiginitrelease+0x1c/0x2c [drm] [ +0.000144] drmmanagedrelease+0x170/0x414 [drm] [ +0.000142] drmdevput.part.0+0xc0/0x124 [drm] [ +0.000143] drmdevput+0x20/0x30 [drm] [ +0.000142] mesondrvunbind+0x1d8/0x2ac [mesondrm] [ +0.000028] takedownaggregatedevice+0xb0/0x160 [ +0.000016] componentdel+0x18c/0x360 [ +0.000009] mesondwhdmiremove+0x28/0x40 [mesondwhdmi] [ +0.000015] platformremove+0x64/0xb0 [ +0.000009] deviceremove+0xb8/0x154 [ +0.000009] devicereleasedriverinternal+0x398/0x5b0 [ +0.000009] driverdetach+0xac/0x1b0 [ +0.000009] busremovedriver+0x158/0x29c [ +0.000009] driverunregister+0x70/0xb0 [ +0.000008] platformdriverunregister+0x20/0x2c [ +0.000008] mesondwhdmiplatformdriverexit+0x1c/0x30 [mesondwhdmi] [ +0.000012] dosysdeletemodule+0x288/0x400 [ +0.000011] arm64sysdeletemodule+0x5c/0x80 [ +0.000009] invokesyscall+0x74/0x260 [ +0.000009] el0svccommon.constprop.0+0xcc/0x260 [ +0.000009] doel0svc+0x50/0x70 [ +0.000007] el0svc+0x68/0x1a0 [ +0.000012] el0t64synchandler+0x11c/0x150 [ +0.000008] el0t64sync+0x18c/0x190

[ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available)

[ +0.000011] Freed by task 2695: [ +0.000008] kasansavestack+0x2c/0x5c [ +0.000011] kasansettrack+0x2c/0x40 [ +0.000008] kasansetfreeinfo+0x28/0x50 [ +0.000009] kasanslabfree+0x128/0x1d4 [ +0.000008] kasanslabfree+0x18/0x24 [ +0.000007] slabfreefreelisthook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] releasenodes+0xf0/0x16c [ +0.000009] devresreleasegroup+0x180/0x270 [ +0.000008] componentunbind+0x128/0x1e0 [ +0.000010] componentunbindall+0x1b8/0x264 [ +0.000009] mesondrvunbind+0x1a0/0x2ac [mesondrm] [ +0.000025] takedownaggregatedevice+0xb0/0x160 [ +0.000009] componentdel+0x18c/0x360 [ +0.000009] mesondwhdmiremove+0x28/0x40 [mesondwhdmi] [ +0.000012] platformremove+0x64/0xb0 [ +0.000008] deviceremove+0xb8/0x154 [ +0.000009] devicereleasedriverinternal+0x398/0x5b0 [ +0.000009] driverdetach+0xac/0x1b0 [ +0.000009] busremovedriver+0x158/0x29c [ +0.000008] driverunregister+0x70/0xb0 [ +0.000008] platformdriverunregister+0x20/0x2c [ +0.000008] mesondwhdmiplatformdriverexit+0x1c/0x30 [mesondwhdmi] [ +0.000011] dosysdeletemodule+0x288/0x400 [ +0.000010] arm64sysdeletemodule+0x5c/0x80 [ +0.000008] invokesyscall+0x74/0x260 [ +0.000008] el0svccommon.constprop.0+0xcc/0x260 [ +0.000008] doel0svc+0x50/0x70 [ +0.000007] el0svc+0x68/0x1a0 [ +0.000009] el0t64synchandler+0x11c/0x150 [ +0.000009] el0t64sync+0x18c/0x190

[ +0.000014] The buggy address belongs to the object at ffff000020c39000 ---truncated---

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

fs: fix UAF/GPF bug in nilfsmdtdestroy

In allocinode, inodeinitalways() could return -ENOMEM if securityinodealloc() fails, which causes inode->iprivate uninitialized. Then nilfsismetadatafileinode() returns true and nilfsfreeinode() wrongly calls nilfsmdtdestroy(), which frees the uninitialized inode->iprivate and leads to crashes(e.g., UAF/GPF).

Fix this by moving securityinodealloc just prior to thiscpuinc(nrinodes)