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

gpio: omap: do not register driver in probe()

Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the omapmpuiodriver from omapmpuioinit(), which is called from omapgpioprobe().

However, it neither makes sense to register drivers from probe() callbacks of other drivers, nor does the driver core allow registering drivers with a device lock already being held.

The latter was revealed by commit dc23806a7c47 ("driver core: enforce devicelock for drivermatchdevice()") leading to a potential deadlock condition described in [1].

Additionally, the omapmpuiodriver is never unregistered from the driver core, even if the module is unloaded.

Hence, register the omapmpuiodriver from the module initcall and unregister it in moduleexit().

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

Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"

This reverts commit 7294863a6f01248d72b61d38478978d638641bee.

This commit was erroneously applied again after commit 0ab5d711ec74 ("drm/amd: Refactor amdgpuaspm to be evaluated per device") removed it, leading to very hard to debug crashes, when used with a system with two AMD GPUs of which only one supports ASPM.

(cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)

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

iouring/zcrx: fix page array leak

d9f595b9a65e ("iouring/zcrx: fix leaking pages on sg init fail") fixed a page leakage but didn't free the page array, release it as well.

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

nvme-fc: release admin tagset if init fails

nvmefabrics creates an NVMe/FC controller in following path:

nvmfdevwrite() -> nvmfcreatectrl() -> nvmefccreatectrl() -> nvmefcinitctrl()

nvmefcinitctrl() allocates the admin blk-mq resources right after nvmeaddctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the failctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.

Check ctrl->ctrl.admintagset in the failctrl path and call nvmeremoveadmintagset() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.

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

regmap: maple: free entry on masstoregfp() failure

regcachemaplewrite() allocates a new block ('entry') to merge adjacent ranges and then stores it with masstoregfp(). When masstoregfp() fails, the new 'entry' remains allocated and is never freed, leaking memory.

Free 'entry' on the failure path; on success continue freeing the replaced neighbor blocks ('lower', 'upper').

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

iouring/rw: free potentially allocated iovec on cache put failure

If a read/write request goes through ioreqrwcleanup() and has an allocated iovec attached and fails to put to the rwcache, then it may end up with an unaccounted iovec pointer. Have iorwrecycle() return whether it recycled the request or not, and use that to gauge whether to free a potential iovec or not.

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

net: liquidio: Initialize netdev pointer before queue setup

In setupnicdevices(), the netdev is allocated using allocetherdevmq(). However, the pointer to this structure is stored in oct->props[i].netdev only after the calls to netifsetrealnumrxqueues() and netifsetrealnumtxqueues().

If either of these functions fails, setupnicdevices() returns an error without freeing the allocated netdev. Since oct->props[i].netdev is still NULL at this point, the cleanup function liquidiodestroynicdevice() will fail to find and free the netdev, resulting in a memory leak.

Fix this by initializing oct->props[i].netdev before calling the queue setup functions. This ensures that the netdev is properly accessible for cleanup in case of errors.

Compile tested only. Issue found using a prototype static analysis tool and code review.

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

net: liquidio: Fix off-by-one error in PF setupnicdevices() cleanup

In setupnicdevices(), the initialization loop jumps to the label setupnicdevfree on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak.

Fix this by changing the loop to iterate from the current index i down to 0.

Also, decrement i in the devlinkalloc failure path to point to the last successfully allocated index.

Compile tested only. Issue found using code review.

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

net: liquidio: Fix off-by-one error in VF setupnicdevices() cleanup

In setupnicdevices(), the initialization loop jumps to the label setupnicdevfree on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak.

Fix this by changing the loop to iterate from the current index i down to 0.

Compile tested only. Issue found using code review.

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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

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

net: gro: fix outer network offset

The udp GRO complete stage assumes that all the packets inserted the RX have the encapsulation flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup.

Due to the above, in the problematic scenarios, udp4grocomplete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing.

Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udpgrocomplete().

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

romfs: check sbsetblocksize() return value

romfsfillsuper() ignores the return value of sbsetblocksize(), which can fail if the requested block size is incompatible with the block device's configuration.

This can be triggered by setting a loop device's block size larger than PAGESIZE using ioctl(LOOPSETBLOCKSIZE, 32768), then mounting a romfs filesystem on that device.

When sbsetblocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logicalblocksize=32768, bdevvalidateblocksize() fails because the requested size is smaller than the device's logical block size. sbsetblocksize() returns 0 (failure), but romfs ignores this and continues mounting.

The superblock's block size remains at the device's logical block size (32768). Later, when sbbread() attempts I/O with this oversized block size, it triggers a kernel BUG in foliosetbh():

kernel BUG at fs/buffer.c:1582! BUGON(size > PAGESIZE);

Fix by checking the return value of sbsetblocksize() and failing the mount with -EINVAL if it returns 0.

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

platform/x86: classmate-laptop: Add missing NULL pointer checks

In a few places in the Classmate laptop driver, code using the accel object may run before that object's address is stored in the driver data of the input device using it.

For example, cmpcaccelsensitivitystorev4() is the "show" method of cmpcaccelsensitivityattrv4 which is added in cmpcacceladdv4(), before calling devsetdrvdata() for inputdev->dev. If the sysfs attribute is accessed prematurely, the devgetdrvdata(&inputdev->dev) call in in cmpcaccelsensitivitystorev4() returns NULL which leads to a NULL pointer dereference going forward.

Moreover, sysfs attributes using the input device are added before initializing that device by cmpcaddacpinotifydevice() and if one of them is accessed before running that function, a NULL pointer dereference will occur.

For example, cmpcaccelsensitivityattrv4 is added before calling cmpcaddacpinotifydevice() and if it is read prematurely, the devgetdrvdata(&acpi->dev) call in cmpcaccelsensitivityshowv4() returns NULL which leads to a NULL pointer dereference going forward.

Fix this by adding NULL pointer checks in all of the relevant places.

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

mm/slab: Add alloctaggingslabfreehook for memcgallocabortsingle

When CONFIGMEMALLOCPROFILINGDEBUG is enabled, the following warning may be noticed:

[ 3959.023862] ------------[ cut here ]------------ [ 3959.023891] alloctag was not cleared (got tag for lib/xarray.c:378) [ 3959.023947] WARNING: ./include/linux/alloctag.h:155 at alloctagadd+0x128/0x178, CPU#6: mkfs.ntfs/113998 [ 3959.023978] Modules linked in: dnsresolver tun brd overlay exfat btrfs blake2b libblake2b xor xorneon raid6pq loop sctp ip6udptunnel udptunnel ext4 crc16 mbcache jbd2 rfkill sunrpc vfat fat sg fuse nfnetlink srmod virtiogpu cdrom drmclientlib virtiodmabuf drmshmemhelper drmkmshelper ghashce drm sm4 backlight virtionet netfailover virtioscsi failover virtioconsole virtioblk virtiommio dmmirror dmregionhash dmlog dmmultipath dmmod i2cdev aesneonbs aesceblk [last unloaded: hwpoisoninject] [ 3959.024170] CPU: 6 UID: 0 PID: 113998 Comm: mkfs.ntfs Kdump: loaded Tainted: G W 6.19.0-rc7+ #7 PREEMPT(voluntary) [ 3959.024182] Tainted: [W]=WARN [ 3959.024186] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 [ 3959.024192] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3959.024199] pc : alloctagadd+0x128/0x178 [ 3959.024207] lr : alloctagadd+0x128/0x178 [ 3959.024214] sp : ffff80008b696d60 [ 3959.024219] x29: ffff80008b696d60 x28: 0000000000000000 x27: 0000000000000240 [ 3959.024232] x26: 0000000000000000 x25: 0000000000000240 x24: ffff800085d17860 [ 3959.024245] x23: 0000000000402800 x22: ffff0000c0012dc0 x21: 00000000000002d0 [ 3959.024257] x20: ffff0000e6ef3318 x19: ffff800085ae0410 x18: 0000000000000000 [ 3959.024269] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 3959.024281] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600064101293 [ 3959.024292] x11: 1fffe00064101292 x10: ffff600064101292 x9 : dfff800000000000 [ 3959.024305] x8 : 00009fff9befed6e x7 : ffff000320809493 x6 : 0000000000000001 [ 3959.024316] x5 : ffff000320809490 x4 : ffff600064101293 x3 : ffff800080691838 [ 3959.024328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000d5bcd640 [ 3959.024340] Call trace: [ 3959.024346] alloctagadd+0x128/0x178 (P) [ 3959.024355] alloctaggingslaballochook+0x11c/0x1a8 [ 3959.024362] kmemcachealloclrunoprof+0x1b8/0x5e8 [ 3959.024369] xasalloc+0x304/0x4f0 [ 3959.024381] xascreate+0x1e0/0x4a0 [ 3959.024388] xasstore+0x68/0xda8 [ 3959.024395] filemapaddfolio+0x5b0/0xbd8 [ 3959.024409] filemapaddfolio+0x16c/0x7e0 [ 3959.024416] filemapgetfoliompol+0x2dc/0x9e8 [ 3959.024424] iomapgetfolio+0xfc/0x180 [ 3959.024435] iomapgetfolio+0x2f8/0x4b8 [ 3959.024441] iomapwritebegin+0x198/0xc18 [ 3959.024448] iomapwriteiter+0x2ec/0x8f8 [ 3959.024454] iomapfilebufferedwrite+0x19c/0x290 [ 3959.024461] blkdevwriteiter+0x38c/0x978 [ 3959.024470] vfswrite+0x4d4/0x928 [ 3959.024482] ksyswrite+0xfc/0x1f8 [ 3959.024489] arm64syswrite+0x74/0xb0 [ 3959.024496] invokesyscall+0xd4/0x258 [ 3959.024507] el0svccommon.constprop.0+0xb4/0x240 [ 3959.024514] doel0svc+0x48/0x68 [ 3959.024520] el0svc+0x40/0xf8 [ 3959.024526] el0t64synchandler+0xa0/0xe8 [ 3959.024533] el0t64sync+0x1ac/0x1b0 [ 3959.024540] ---[ end trace 0000000000000000 ]---

When memcgslabpostallochook() fails, there are two different free paths depending on whether size == 1 or size != 1. In the kmemcachefreebulk() path, we do call alloctaggingslabfreehook(). However, in memcgallocabortsingle() we don't, the above warning will be triggered on the next allocation.

Therefore, add alloctaggingslabfreehook() to the memcgallocabortsingle() path.

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

gpio: loongson-64bit: Fix incorrect NULL check after devmkcalloc()

Fix incorrect NULL check in loongsongpioinitirqchip(). The function checks chip->parent instead of chip->irq.parents.

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

x86/vmware: Fix hypercall clobbers

Fedora QA reported the following panic:

BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmwarehypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmousereportevents+0x13e/0x1b0 psmousehandlebyte+0x15/0x60 ps2interrupt+0x8a/0xd0 ...

because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in.

The QEMU vmmouse driver saves and restores the register state in a "uint32t data[6];" and as a result restores the state with the high bits all cleared.

RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced.

The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall.

In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmwarehypercall3() and vmwarehypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls.

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

btrfs: reject new transactions if the fs is fully read-only

[BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount:

BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:findfreeextentupdateloop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:findfreeextent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: <TASK> btrfsreserveextent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfsalloctreeblock+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfsforcecowblock+0x578/0x2410 fs/btrfs/ctree.c:517 btrfscowblock+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfssearchslot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfstruncateinodeitems+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfsevictinode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 dentrykill+0x209/0x660 fs/dcache.c:670 finishdput+0xc9/0x480 fs/dcache.c:879 shrinkdcacheforumount+0xa0/0x170 fs/dcache.c:1661 genericshutdownsuper+0x67/0x2c0 fs/super.c:621 killanonsuper+0x3b/0x70 fs/super.c:1289 btrfskillsuper+0x41/0x50 fs/btrfs/super.c:2127 deactivatelockedsuper+0xbc/0x130 fs/super.c:474 cleanupmnt+0x425/0x4c0 fs/namespace.c:1318 taskworkrun+0x1d4/0x260 kernel/taskwork.c:233 exittaskwork include/linux/taskwork.h:40 [inline] doexit+0x694/0x22f0 kernel/exit.c:971 dogroupexit+0x21c/0x2d0 kernel/exit.c:1112 dosysexitgroup kernel/exit.c:1123 [inline] sesysexitgroup kernel/exit.c:1121 [inline] x64sysexitgroup+0x3f/0x40 kernel/exit.c:1121 x64syscall+0x2210/0x2210 arch/x86/include/generated/asm/syscalls64.h:232 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe8/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>

Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered.

But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs.

[CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do.

However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions.

[FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.

bonding: annotate data-races around slave->lastrx

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

mm, swap: restore swapspace attr aviod kernel panic

commit 8b47299a411a ("mm, swap: mark swap address space ro and add context debug check") made the swap address space read-only. It may lead to kernel panic if archpreparetoswap returns a failure under heavy memory pressure as follows,

el1abort+0x40/0x64 el1h64synchandler+0x48/0xcc el1h64sync+0x84/0x88 errseqset+0x4c/0xb8 (P) filemapsetwberr+0x20/0xd0 shrinkfoliolist+0xc20/0x11cc evictfolios+0x1520/0x1be4 trytoshrinklruvec+0x27c/0x3dc shrinkone+0x9c/0x228 shrinknode+0xb3c/0xeac dotrytofreepages+0x170/0x4f0 trytofreepages+0x334/0x534 allocpagesdirectreclaim+0x90/0x158 allocpagesslowpath+0x334/0x588 allocfrozenpagesnoprof+0x224/0x2fc folioallocnoprof+0x14/0x64 vmaalloczeroedmovablefolio+0x34/0x44 doptemissing+0xad4/0x1040 handlemmfault+0x4a4/0x790 dopagefault+0x288/0x5f8 dotranslationfault+0x38/0x54 domemabort+0x54/0xa8

Restore swap address space as not ro to avoid the panic.

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

ice: Fix PTP NULL pointer dereference during VSI rebuild

Fix race condition where PTP periodic work runs while VSI is being rebuilt, accessing NULL vsi->rxrings.

The sequence was: 1. iceptpprepareforreset() cancels PTP work 2. iceptprebuild() immediately queues PTP work 3. VSI rebuild happens AFTER iceptprebuild() 4. PTP work runs and accesses NULL vsi->rxrings

Fix: Keep PTP work cancelled during rebuild, only queue it after VSI rebuild completes in icerebuild().

Added iceptpqueuework() helper function to encapsulate the logic for queuing PTP work, ensuring it's only queued when PTP is supported and the state is ICEPTPREADY.

Error log: [ 121.392544] ice 0000:60:00.1: PTP reset successful [ 121.392692] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 121.392712] #PF: supervisor read access in kernel mode [ 121.392720] #PF: errorcode(0x0000) - not-present page [ 121.392727] PGD 0 [ 121.392734] Oops: Oops: 0000 [#1] SMP NOPTI [ 121.392746] CPU: 8 UID: 0 PID: 1005 Comm: ice-ptp-0000:60 Tainted: G S 6.19.0-rc6+ #4 PREEMPT(voluntary) [ 121.392761] Tainted: [S]=CPUOUTOFSPEC [ 121.392773] RIP: 0010:iceptpupdatecachedphctime+0xbf/0x150 [ice] [ 121.393042] Call Trace: [ 121.393047] <TASK> [ 121.393055] iceptpperiodicwork+0x69/0x180 [ice] [ 121.393202] kthreadworkerfn+0xa2/0x260 [ 121.393216] ? pfxiceptpperiodicwork+0x10/0x10 [ice] [ 121.393359] ? pfxkthreadworkerfn+0x10/0x10 [ 121.393371] kthread+0x10d/0x230 [ 121.393382] ? pfxkthread+0x10/0x10 [ 121.393393] retfromfork+0x273/0x2b0 [ 121.393407] ? pfxkthread+0x10/0x10 [ 121.393417] retfromforkasm+0x1a/0x30 [ 121.393432] </TASK>

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

spi: tegra210-quad: Protect currxfer check in IRQ handler

Now that all other accesses to currxfer are done under the lock, protect the currxfer NULL check in tegraqspiisrthread() with the spinlock. Without this protection, the following race can occur:

CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->currxfer) // sees non-NULL spinlock() tqspi->currxfer = NULL spinunlock() handlexfer() spinlock() t = tqspi->currxfer // NULL! ... t->len ... // NULL dereference!

With this patch, all currxfer accesses are now properly synchronized.

Although all accesses to currxfer are done under the lock, in tegraqspiisrthread() it checks for NULL, releases the lock and reacquires it later in handlecpubasedxfer()/handledmabasedxfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.

To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared currxfer, the handler will safely return without dereferencing the NULL pointer.

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

dpaa2-switch: prevent ZEROSIZEPTR dereference when numifs is zero

The driver allocates arrays for ports, FDBs, and filter blocks using kcalloc() with ethsw->swattr.numifs as the element count. When the device reports zero interfaces (either due to hardware configuration or firmware issues), kcalloc(0, ...) returns ZEROSIZEPTR (0x10) instead of NULL.

Later in dpaa2switchprobe(), the NAPI initialization unconditionally accesses ethsw->ports[0]->netdev, which attempts to dereference ZEROSIZEPTR (address 0x10), resulting in a kernel panic.

Add a check to ensure numifs is greater than zero after retrieving device attributes. This prevents the zero-sized allocations and subsequent invalid pointer dereference.

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

smb/client: fix memory leak in smb2openfile()

Reproducer:

1. server: directories are exported read-only 2. client: mount -t cifs //${serverip}/export /mnt 3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct 4. client: umount /mnt 5. client: sleep 1 6. client: modprobe -r cifs

The error message is as follows:

============================================================================= BUG cifssmallrq (Not tainted): Objects remaining on kmemcacheshutdown() -----------------------------------------------------------------------------

Object 0x00000000d47521be @offset=14336 ... WARNING: mm/slub.c:1251 at kmemcacheshutdown+0x34e/0x440, CPU#0: modprobe/1577 ... Call Trace: <TASK> kmemcachedestroy+0x94/0x190 cifsdestroyrequestbufs+0x3e/0x50 [cifs] cleanupmodule+0x4e/0x540 [cifs] sesysdeletemodule+0x278/0x400 x64sysdeletemodule+0x5f/0x70 x64syscall+0x2299/0x2ff0 dosyscall64+0x89/0x350 entrySYSCALL64afterhwframe+0x76/0x7e ... kmemcachedestroy cifssmallrq: Slab cache still has objects when called from cifsdestroyrequestbufs+0x3e/0x50 [cifs] WARNING: mm/slabcommon.c:532 at kmemcachedestroy+0x16b/0x190, CPU#0: modprobe/1577

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

net: cpswnew: Execute ndosetrxmode callback in a work queue

Commit 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6ADDMEMBERSHIP and MCASTJOINGROUP.") removed the RTNL lock for IPV6ADDMEMBERSHIP and MCASTJOINGROUP operations. However, this change triggered the following call trace on my BeagleBone Black board: WARNING: net/8021q/vlancore.c:236 at vlanforeach+0x120/0x124, CPU#0: rpcbind/496 RTNL: assertion failed at net/8021q/vlancore.c (236) Modules linked in: CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwindbacktrace from showstack+0x28/0x2c showstack from dumpstacklvl+0x30/0x38 dumpstacklvl from warn+0xb8/0x11c warn from warnslowpathfmt+0x130/0x194 warnslowpathfmt from vlanforeach+0x120/0x124 vlanforeach from cpswaddmcaddr+0x54/0xd8 cpswaddmcaddr from hwaddrrefsyncdev+0xc4/0xec hwaddrrefsyncdev from devmcadd+0x78/0x88 devmcadd from igmp6groupadded+0x84/0xec igmp6groupadded from ipv6devmcinc+0x1fc/0x2f0 ipv6devmcinc from ipv6sockmcjoin+0x124/0x1b4 ipv6sockmcjoin from doipv6setsockopt+0x84c/0x1168 doipv6setsockopt from ipv6setsockopt+0x88/0xc8 ipv6setsockopt from dosocksetsockopt+0xe8/0x19c dosocksetsockopt from syssetsockopt+0x84/0xac syssetsockopt from retfastsyscall+0x0/0x5

This trace occurs because vlanforeach() is called within cpswndosetrxmode(), which expects the RTNL lock to be held. Since modifying vlanforeach() to operate without the RTNL lock is not straightforward, and because ndosetrxmode() is invoked both with and without the RTNL lock across different code paths, simply adding rtnllock() in cpswndosetrxmode() is not a viable solution.

To resolve this issue, we opt to execute the actual processing within a work queue, following the approach used by the icssg-prueth driver.

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

spi: tegra210-quad: Protect currxfer in tegraqspicombinedseqxfer

The currxfer field is read by the IRQ handler without holding the lock to check if a transfer is in progress. When clearing currxfer in the combined sequence transfer loop, protect it with the spinlock to prevent a race with the interrupt handler.

Protect the currxfer clearing at the exit path of tegraqspicombinedseqxfer() with the spinlock to prevent a race with the interrupt handler that reads this field.

Without this protection, the IRQ handler could read a partially updated currxfer value, leading to NULL pointer dereference or use-after-free.

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

ceph: fix oops due to invalid pointer for kfree() in parselongname()

This fixes a kernel oops when reading ceph snapshot directories (.snap), for example by simply running ls /mnt/myceph/.snap.

The variable str is guarded by free(kfree), but advanced by one for skipping the initial '' in snapshot names. Thus, kfree() is called with an invalid pointer. This patch removes the need for advancing the pointer so kfree() is called with correct memory pointer.

Steps to reproduce:

1. Create snapshots on a cephfs volume (I've 63 snaps in my testcase)

2. Add cephfs mount to fstab $ echo "samba-fileserver@.files=/volumes/datapool/stuff/3461082b-ecc9-4e82-8549-3fd2590d3fb6 /mnt/test/stuff ceph acl,noatime,netdev 0 0" >> /etc/fstab

3. Reboot the system $ systemctl reboot

4. Check if it's really mounted $ mount | grep stuff

5. List snapshots (expected 63 snapshots on my system) $ ls /mnt/test/stuff/.snap

Now ls hangs forever and the kernel log shows the oops.

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

ipv6: Fix ECMP sibling count mismatch when clearing RTFADDRCONF

syzbot reported a kernel BUG in fib6addrt2node() when adding an IPv6 route. [0]

Commit f72514b3c569 ("ipv6: clear RA flags when adding a static route") introduced logic to clear RTFADDRCONF from existing routes when a static route with the same nexthop is added. However, this causes a problem when the existing route has a gateway.

When RTFADDRCONF is cleared from a route that has a gateway, that route becomes eligible for ECMP, i.e. rt6qualifyforecmp() returns true. The issue is that this route was never added to the fib6siblings list.

This leads to a mismatch between the following counts:

- The sibling count computed by iterating fib6next chain, which includes the newly ECMP-eligible route

- The actual siblings in fib6siblings list, which does not include that route

When a subsequent ECMP route is added, fib6addrt2node() hits BUGON(sibling->fib6nsiblings != rt->fib6nsiblings) because the counts don't match.

Fix this by only clearing RTFADDRCONF when the existing route does not have a gateway. Routes without a gateway cannot qualify for ECMP anyway (rt6qualifyforecmp() requires fibnhgwfamily), so clearing RTFADDRCONF on them is safe and matches the original intent of the commit.

[0]: kernel BUG at net/ipv6/ip6fib.c:1217! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:fib6addrt2node+0x3433/0x3470 net/ipv6/ip6fib.c:1217 [...] Call Trace: <TASK> fib6add+0x8da/0x18a0 net/ipv6/ip6fib.c:1532 ip6insrt net/ipv6/route.c:1351 [inline] ip6routeadd+0xde/0x1b0 net/ipv6/route.c:3946 ipv6routeioctl+0x35c/0x480 net/ipv6/route.c:4571 inet6ioctl+0x219/0x280 net/ipv6/afinet6.c:577 sockdoioctl+0xdc/0x300 net/socket.c:1245 sockioctl+0x576/0x790 net/socket.c:1366 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl+0xfc/0x170 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xfa/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

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

procfs: avoid fetching build ID while holding VMA lock

Fix PROCMAPQUERY to fetch optional build ID only after dropping mmaplock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot:

-> #1 (&mm->mmaplock){++++}-{4:4}: mightfault+0xed/0x170 copytoiter+0x118/0x1720 copypagetoiter+0x12d/0x1e0 filemapread+0x720/0x10a0 blkdevreaditer+0x2b5/0x4e0 vfsread+0x7f4/0xae0 ksysread+0x12a/0x250 dosyscall64+0xcb/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

-> #0 (&sb->stype->imutexkey#8){++++}-{4:4}: lockacquire+0x1509/0x26d0 lockacquire+0x185/0x340 downread+0x98/0x490 blkdevreaditer+0x2a7/0x4e0 kernelread+0x39a/0xa90 freaderfetch+0x1d5/0xa80 buildidparse.isra.0+0xea/0x6a0 doprocmapquery+0xd75/0x1050 procfsprocmapioctl+0x7a/0xb0 x64sysioctl+0x18e/0x210 dosyscall64+0xcb/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0 CPU1 ---- ---- rlock(&mm->mmaplock); lock(&sb->stype->imutexkey#8); lock(&mm->mmaplock); rlock(&sb->stype->imutexkey#8);

DEADLOCK

This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent:

777a8560fd29 ("lib/buildid: use kernelread() for sleepable context")

To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal buildidparse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant buildidparsefile() that expects file passed directly.

[akpm: fix up kerneldoc]

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

i2c: imx: preserve error state in block data length handler

When a block read returns an invalid length, zero or >I2CSMBUSBLOCKMAX, the length handler sets the state to IMXI2CSTATEFAILED. However, i2cimxmasterisr() unconditionally overwrites this with IMXI2CSTATEREADCONTINUE, causing an endless read loop that overruns buffers and crashes the system.

Guard the state transition to preserve error states set by the length handler.

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

ASoC: amd: fix memory leak in acp3x pdm dma ops