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:

LoongArch: Enable exception fixup for specific ADE subcode

This patch allows the LoongArch BPF JIT to handle recoverable memory access errors generated by BPFPROBEMEM instructions.

When a BPF program performs memory access operations, the instructions it executes may trigger ADEM exceptions. The kernel’s built-in BPF exception table mechanism (EXTYPEBPF) will generate corresponding exception fixup entries in the JIT compilation phase; however, the architecture-specific trap handling function needs to proactively call the common fixup routine to achieve exception recovery.

doade(): fix EXTYPEBPF memory access exceptions for BPF programs, ensure safe execution.

Relevant test cases: illegal address access tests in moduleattach and subprogsextable of selftests/bpf.

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:

riscv: trace: fix snapshot deadlock with sbi ecall

If sbiecall.c's functions are traceable,

echo "sbiecall:snapshot" > /sys/kernel/tracing/setftracefilter

may get the kernel into a deadlock.

(Functions in sbiecall.c are excluded from tracing if CONFIGRISCVALTERNATIVEEARLY is set.)

sbiecall triggers a snapshot of the ringbuffer. The snapshot code raises an IPI interrupt, which results in another call to sbiecall and another snapshot...

All it takes to get into this endless loop is one initial sbiecall. On RISC-V systems without SSTC extension, the clock events in timer-riscv.c issue periodic sbi ecalls, making the problem easy to trigger.

Always exclude the sbiecall.c functions from tracing to fix the potential deadlock.

sbi ecalls can easiliy be logged via trace events, excluding ecall functions from function tracing is not a big limitation.

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.

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

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.

To prevent this, set the nohwaccess flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.

A memory barrier smpmb() is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.

(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)

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

wifi: mac80211: don't WARN for connections on invalid channels

It's not clear (to me) how exactly syzbot managed to hit this, but it seems conceivable that e.g. regulatory changed and has disabled a channel between scanning (channel is checked to be usable by cfg80211getieschannelnumber) and connecting on the channel later.

With one scenario that isn't covered elsewhere described above, the warning isn't good, replace it with a (more informative) error message.

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

md: suspend array while updating raiddisks via sysfs

In raid1reshape(), freezearray() is called before modifying the r1bio memory pool (conf->r1biopool) and conf->raiddisks, and unfreezearray() is called after the update is completed.

However, freezearray() only waits until nrsyncpending and (nrpending - nrqueued) of all buckets reaches zero. When an I/O error occurs, nrqueued is increased and the corresponding r1bio is queued to either retrylist or bioendiolist. As a result, freezearray() may unblock before these r1bios are released.

This can lead to a situation where conf->raiddisks and the mempool have already been updated while queued r1bios, allocated with the old raiddisks value, are later released. Consequently, freer1bio() may access memory out of bounds in putallbios() and release r1bios of the wrong size to the new mempool, potentially causing issues with the mempool as well.

Since only normal I/O might increase nrqueued while an I/O error occurs, suspending the array avoids this issue.

Note: Updating raiddisks via ioctl SETARRAYINFO already suspends the array. Therefore, we suspend the array when updating raiddisks via sysfs to avoid this issue too.

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.