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

drm/ttm: Fix ttmboswapout() infinite LRU walk on swapout failure

When ttmttswapout() fails, the current code calls ttmresourceaddbulkmove() followed by ttmresourcemovetolrutail() to restore the resource's bulkmove membership.

However, ttmresourcemovetolrutail() places the resource at the tail of the LRU list which, relative to the walk cursor's hitch node (placed immediately after the resource when it was yielded), puts the resource in front of the the hitch. The next listforeachentrycontinue() from the hitch finds the same resource again, causing an infinite loop.

Fix by deferring delbulkmove to the success path only.

On the success path, TTMTTFLAGSWAPPED has just been set by ttmttswapout() but the resource is still tracked in the bulkmove range, so ttmresourcedelbulkmove()'s !ttmresourceunevictable() guard would incorrectly skip the removal. Introduce ttmresourcedelbulkmoveunevictable() which bypasses that guard.

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

blktrace: fix thiscpuread/write in preemptible context

tracingrecordcmdline() internally uses thiscpuread() and thiscpuwrite() on the per-CPU variable tracecmdlinesave, and tracesavecmdline() explicitly asserts preemption is disabled via lockdepassertpreemptiondisabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probewakeupschedswitch() / probewakeup()).

blkaddtrace() was calling tracingrecordcmdline(current) early in the blktracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002:

blktrace/002 (blktrace ftrace corruption with sysfs trace) [failed] runtime 0.367s ... 0.437s something found in dmesg: [ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] nullblk: disk nullb1 created [ 81.357294] BUG: using thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 ... (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)

[ 81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [ 81.239580] nullblk: disk nullb1 created [ 81.357294] BUG: using thiscpuread() in preemptible [00000000] code: dd/2516 [ 81.362842] caller is tracingrecordcmdline+0x10/0x40 [ 81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G N 7.0.0-rc1lblk+ #84 PREEMPT(full) [ 81.362877] Tainted: [N]=TEST [ 81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 81.362881] Call Trace: [ 81.362884] <TASK> [ 81.362886] dumpstacklvl+0x8d/0xb0 [ 81.362895] checkpreemptiondisabled+0xce/0xe0 [ 81.362902] tracingrecordcmdline+0x10/0x40 [ 81.362923] blkaddtrace+0x307/0x5d0 [ 81.362934] ? lockacquire+0xe0/0x300 [ 81.362940] ? ioviterextractpages+0x101/0xa30 [ 81.362959] blkaddtracebio+0x106/0x1e0 [ 81.362968] submitbionoacctnocheck+0x24b/0x3a0 [ 81.362979] ? lockdepinitmaptype+0x58/0x260 [ 81.362988] submitbiowait+0x56/0x90 [ 81.363009] blkdevdirectIOsimple+0x16c/0x250 [ 81.363026] ? pfxsubmitbiowaitendio+0x10/0x10 [ 81.363038] ? rcureadlockanyheld+0x73/0xa0 [ 81.363051] blkdevreaditer+0xc1/0x140 [ 81.363059] vfsread+0x20b/0x330 [ 81.363083] ksysread+0x67/0xe0 [ 81.363090] dosyscall64+0xbf/0xf00 [ 81.363102] entrySYSCALL64afterhwframe+0x76/0x7e [ 81.363106] RIP: 0033:0x7f281906029d [ 81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [ 81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [ 81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [ 81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [ 81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [ 81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [ 81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [ 81.363142] </TASK>

The same BUG fires from blkaddtraceplug(), blkaddtraceunplug(), and blkaddtracerq() paths as well.

The purpose of tracin ---truncated---

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

net: bcmasp: fix txspbringfull() checking same slot cnt times

The loop initialised nextindex from intf->txspbindex on every iteration, so incrring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances nextindex and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission.

btrfs: do not force reloc root creation during qgroupaccountsnapshot()

btrfs: fix the possible bioclist memory leak during error

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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

cgroup: split cgroupdestroywq into 3 workqueues

block: avoid possible overflow for chunksectors check in blkstacklimits()

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

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

net: bridge: fix soft lockup in brmulticastqueryexpired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastqueryinterval ip link set dev br0 up

The multicaststartupqueryinterval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.

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

jbd2: prevent softlockup in jbd2logdocheckpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlistlock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfromfork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.

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

crypto: qat - flush misc workqueue during device shutdown

Repeated loading and unloading of a device specific QAT driver, for example qat4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat4xxx.ko) is unloaded, while the core driver (intelqat.ko) remains loaded.

Since the driver uses a shared workqueue (qatmiscwq) across all devices and owned by intelqat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following:

BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pmbhhandler+0x1d2/0x250 [intelqat] Call Trace: pmbhhandler+0x1d2/0x250 [intelqat] processonework+0x171/0x340 workerthread+0x277/0x3a0 kthread+0xf0/0x120 retfromfork+0x2d/0x50

To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.

Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.

bpf: Forget ranges when refining tnum after JSET

fs: Prevent file descriptor table allocations exceeding INTMAX

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

x86/cpu/hygon: Add missing resctrlcpudetect() in bspinit helper

Since

923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")

resctrlcpudetect() has been moved from common CPU initialization code to the vendor-specific BSP init helper, while Hygon didn't put that call in their code.

This triggers a division by zero fault during early booting stage on our machines with X86FEATURECQM supported, where getrdtmonresources() tries to calculate monl3config with uninitialized bootcpudata.x86cacheoccscale.

Add the missing resctrlcpudetect() in the Hygon BSP init helper.

[ bp: Massage commit message. ]

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

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

Input: mtk-pmic-keys - fix possible null pointer dereference

In mtkpmickeysprobe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer.

Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.

block: fix resource leak in blkregisterqueue() error path

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

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

1. Those who call dsaswitchsuspend() and dsaswitchresume() from their device PM ops: qca8k-8xxx, bcmsf2, microchip ksz 2. Those who don't: all others. The above methods should be optional.

For type 1, dsaswitchsuspend() calls dsausersuspend() -> phylinkstop(), and dsaswitchresume() calls dsauserresume() -> phylinkstart(). These seem good candidates for setting macmanagedpm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdiobusphysuspend() and mdiobusphyresume() should run in full), I have noticed that the following warning from mdiobusphyresume() is triggered:

WARNON(phydev->state != PHYHALTED && phydev->state != PHYREADY && phydev->state != PHYUP);

because the PHY state machine is running.

It's running as a result of a previous dsauseropen() -> ... -> phylinkstart() -> phystart() having been initiated by the user.

The previous mdiobusphysuspend() was supposed to have called phystopmachine(), but it didn't. So this is why the PHY is in state PHYNOLINK by the time mdiobusphyresume() runs.

mdiobusphysuspend() did not call phystopmachine() because for phylink, the phydev->adjustlink function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARNON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming macmanagedpm is set correctly, a quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINKNETDEV drivers/ | xargs -0 grep -L macmanagedpm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5main.c drivers/net/ethernet/microchip/lan966x/lan966xmain.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fsenet/fsenet-main.c drivers/net/ethernet/freescale/dpaa/dpaaeth.c drivers/net/ethernet/freescale/uccgeth.c drivers/net/ethernet/freescale/enetc/enetcpfcommon.c drivers/net/ethernet/marvell/mvpp2/mvpp2main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/presteramain.c drivers/net/ethernet/mediatek/mtkethsoc.c drivers/net/ethernet/altera/alteratsemain.c drivers/net/ethernet/wangxun/txgbe/txgbephy.c drivers/net/ethernet/meta/fbnic/fbnicphylink.c drivers/net/ethernet/tehuti/tn40phy.c drivers/net/ethernet/mscc/ocelotnet.c

Make the existing conditions dependent on the PHY device having a phydev->phylinkchange() implementation equal to the default phylinkchange() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylinkphychange() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phylinkchange() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b ---truncated---

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

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak

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

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402thermalprobe().

Note, under the same directory, int3400thermalprobe() has such a check.

[ rjw: Subject edit, added Fixes: ]

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

net: Fix null-ptr-deref by socklockinitclassandname() and rmmod.

When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]

Reproduction Steps:

1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule

At step 3), the CIFS module calls sockrelease() for the underlying TCP socket, and it returns quickly. However, the socket remains in FINWAIT1 because incoming FIN packets are dropped.

At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds.

# ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445

# lsmod | grep cifs cifs 1159168 0

This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sockrelease() and it returns, the TCP socket does not die immediately in order to close the connection gracefully.

While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sklock using socklockinitclassandname().

Once an incoming packet is processed for the socket or a timer fires, sk->sklock is acquired.

Then, LOCKDEP checks the lock context in checkwaitcontext(), where hlockclass() is called to retrieve the lock class. However, since the module has already been unloaded, hlockclass() logs a warning and returns NULL, triggering the null-ptr-deref.

If LOCKDEP is enabled, we must ensure that a module calling socklockinitclassandname() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue.

Let's hold the module reference in socklockinitclassandname() and release it when the socket is freed in skprotfree().

Note that socklockinit() clears sk->skowner for svccreatesocket() that calls socklockinitclassandname() for a listening socket, which clones a socket by skclonelock() without GFPZERO.

[0]: CIFSSERVER="10.0.0.137" CIFSPATH="//${CIFSSERVER}/Users/Administrator/Desktop/CIFSTEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt"

MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFSPATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echointerval=1

iptables -A INPUT -s ${CIFSSERVER} -j DROP

for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done

rm -r ${MNT}

iptables -D INPUT -s ${CIFSSERVER} -j DROP

[1]: DEBUGLOCKSWARNON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifsarc4 nlsucs2utils cifsmd4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> lockacquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lockacquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) rawspinlocknested (kernel/locking/spinlock.c:379) tcpv4rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcpipv4.c:2350) ...

BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockacquire (kernel/ ---truncated---

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

net: mvpp2: Prevent parser TCAM memory corruption

Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications.

Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row.

This issue was detected in a situation where mvpp2setrxmode() ran concurrently on two CPUs. In this particular case the MVPP2PEMACUCPROMISCUOUS entry was corrupted, causing the classifier unit to drop all incoming unicast - indicated by the rxclassifierdrops counter.

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

PCI: brcmstb: Fix error path after a call to regulatorbulkget()

If the regulatorbulkget() returns an error and no regulators are created, we need to set their number to zero.

If we don't do this and the PCIe link up fails, a call to the regulatorbulkfree() will result in a kernel panic.

While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from addbus().

[kwilczynski: commit log, use comma in the message to match style with other similar messages]

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

ipv6: Fix memleak of nhcpcpurthoutput in fibchecknhv6gw().

fibchecknhv6gw() expects that fib6nhinit() cleans up everything when it fails.

Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6nh") moved fibnhcommoninit() before allocpercpugfp() within fib6nhinit() but forgot to add cleanup for fib6nh->nhcommon.nhcpcpurthoutput in case it fails to allocate fib6nh->rt6ipcpu, resulting in memleak.

Let's call fibnhcommonrelease() and clear nhcpcpurthoutput in the error path.

Note that we can remove the fib6nhrelease() call in nhcreateipv6() later in net-next.git.

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

llc: do not use skbget() before devqueuexmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKBSHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKBSHARING, this is an orthogonal change.

We need to audit other skbget() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> skbpad+0x18a/0x610 net/core/skbuff.c:2466 skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 devxmitskb net/core/dev.c:4045 [inline] devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsgnosec net/socket.c:718 [inline]

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

x86/amdnb: Use rdmsrsafe() in amdgetmmconfigrange()

Xen doesn't offer MSRFAM10HMMIOCONFBASE to all guests. This results in the following warning:

unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xendoreadmsr+0x7f/0xa0) Call Trace: xenreadmsr+0x1e/0x30 amdgetmmconfigrange+0x2b/0x80 quirkamdmmconfigarea+0x28/0x100 pnpfixupdevice+0x39/0x50 pnpadddevice+0xf/0x150 pnpadddevice+0x3d/0x100 pnpacpiadddevicehandler+0x1f9/0x280 acpinsgetdevicecallback+0x104/0x1c0 acpinswalknamespace+0x1d0/0x260 acpigetdevices+0x8a/0xb0 pnpacpiinit+0x50/0x80 dooneinitcall+0x46/0x2e0 kernelinitfreeable+0x1da/0x2f0 kernelinit+0x16/0x1b0 retfromfork+0x30/0x50 retfromforkasm+0x1b/0x30

based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.

This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.

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

gtp: Suppress list corruption splat in gtpnetexitbatchrtnl().

Brad Spengler reported the listdel() corruption splat in gtpnetexitbatchrtnl(). [0]

Commit eb28fd76c0a0 ("gtp: Destroy device along with udp socket's netns dismantle.") added the foreachnetdev() loop in gtpnetexitbatchrtnl() to destroy devices in each netns as done in geneve and ip tunnels.

However, this could trigger ->dellink() twice for the same device during ->exitbatchrtnl().

Say we have two netns A & B and gtp device B that resides in netns B but whose UDP socket is in netns A.

1. cleanupnet() processes netns A and then B.

2. gtpnetexitbatchrtnl() finds the device B while iterating netns A's gn->gtpdevlist and calls ->dellink().

[ device B is not yet unlinked from netns B as unregisternetdevicemany() has not been called. ]

3. gtpnetexitbatchrtnl() finds the device B while iterating netns B's foreachnetdev() and calls ->dellink().

gtpdellink() cleans up the device's hash table, unlinks the dev from gn->gtpdevlist, and calls unregisternetdevicequeue().

Basically, calling gtpdellink() multiple times is fine unless CONFIGDEBUGLIST is enabled.

Let's remove foreachnetdev() in gtpnetexitbatchrtnl() and delegate the destruction to defaultdeviceexitbatch() as done in bareudp.

[0]: listdel corruption, ffff8880aaa62c00->next (autoslabsizeMdevPnetcoredev11127813288S4096A64n139+0xc00/0x1000 [slab object]) is LISTPOISON1 (ffffffffffffff02) (prev is 0xffffffffffffff04) kernel BUG at lib/listdebug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 UID: 0 PID: 1804 Comm: kworker/u8:7 Tainted: G T 6.12.13-grsec-full-20250211091339 #1 Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: netns cleanupnet RIP: 0010:[<ffffffff84947381>] listdelentryvalidorreport+0x141/0x200 lib/listdebug.c:58 Code: c2 76 91 31 c0 e8 9f b1 f7 fc 0f 0b 4d 89 f0 48 c7 c1 02 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 e0 c2 76 91 31 c0 e8 7f b1 f7 fc <0f> 0b 4d 89 e8 48 c7 c1 04 ff ff ff 48 89 ea 48 89 ee 48 c7 c7 60 RSP: 0018:fffffe8040b4fbd0 EFLAGS: 00010283 RAX: 00000000000000cc RBX: dffffc0000000000 RCX: ffffffff818c4054 RDX: ffffffff84947381 RSI: ffffffff818d1512 RDI: 0000000000000000 RBP: ffff8880aaa62c00 R08: 0000000000000001 R09: fffffbd008169f32 R10: fffffe8040b4f997 R11: 0000000000000001 R12: a1988d84f24943e4 R13: ffffffffffffff02 R14: ffffffffffffff04 R15: ffff8880aaa62c08 RBX: kasan shadow of 0x0 RCX: wakeupklogd.part.0+0x74/0xe0 kernel/printk/printk.c:4554 RDX: listdelentryvalidorreport+0x141/0x200 lib/listdebug.c:58 RSI: vprintk+0x72/0x100 kernel/printk/printksafe.c:71 RBP: autoslabsizeMdevPnetcoredev11127813288S4096A64n139+0xc00/0x1000 [slab object] RSP: process kstack fffffe8040b4fbd0+0x7bd0/0x8000 [kworker/u8:7+netns 1804 ] R09: kasan shadow of process kstack fffffe8040b4f990+0x7990/0x8000 [kworker/u8:7+netns 1804 ] R10: process kstack fffffe8040b4f997+0x7997/0x8000 [kworker/u8:7+netns 1804 ] R15: autoslabsizeMdevPnetcoredev11127813288S4096A64n139+0xc08/0x1000 [slab object] FS: 0000000000000000(0000) GS:ffff888116000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000748f5372c000 CR3: 0000000015408000 CR4: 00000000003406f0 shadow CR4: 00000000003406f0 Stack: 0000000000000000 ffffffff8a0c35e7 ffffffff8a0c3603 ffff8880aaa62c00 ffff8880aaa62c00 0000000000000004 ffff88811145311c 0000000000000005 0000000000000001 ffff8880aaa62000 fffffe8040b4fd40 ffffffff8a0c360d Call Trace: <TASK> [<ffffffff8a0c360d>] listdelentryvalid include/linux/list.h:131 [inline] fffffe8040b4fc28 [<ffffffff8a0c360d>] listdelentry include/linux/list.h:248 [inline] fffffe8040b4fc28 [<ffffffff8a0c360d>] listdel include/linux/list.h:262 [inl ---truncated---