futex: Prevent lockup in requeue-PI during signal/ timeout wakeup

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

net: qrtr: ns: Limit the maximum server registration per node

Current code does no bound checking on the number of servers added per node. A malicious client can flood NEWSERVER messages and exhaust memory.

Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEWSERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtrnsworker().

Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

Bluetooth: btmtk: fix urb->setuppacket leak in error paths

The setuppacket of control urb is not freed if usbsubmiturb fails or the submitted urb is killed. Add free in these two paths.

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

pdscore: fix debugfslookup dentry leak and error handling

debugfslookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.

Additionally, when CONFIGDEBUGFS is disabled, debugfslookup() returns ERRPTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.

drivers/base/memory: set mem->altmap after successful device registration

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

wifi: ath11k: fix error path leaks in some WMI WOW calls

Fix two instances where we used to directly return the result of ath11kwmicmdsend(...). Because we did not check the return value, we also did not free the skb in the error path.

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

netfs: Fix partial invalidation of streaming-write folio

In netfsinvalidatefolio(), if the region of a partial invalidation overlaps the front (but not all) of a dirty write cached in a streaming write page (dirty, but not uptodate, with the dirty region tracked by a netfsfolio struct), the function modifies the dirty region - but incorrectly as it moves the region forward by setting the start to the start, not the end, of the invalidation region.

Fix this by setting finfo->dirtyoffset to the end of the invalidation region (iend).

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

module: decompress: check return value of moduleextendmaxpages()

moduleextendmaxpages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.

If the initial allocation fails, info->pages remains NULL and info->maxpages remains 0. Subsequent calls to modulegetnextpage() will attempt to dynamically grow the array by calling moduleextendmaxpages(info, 0) since info->usedpages is 0. This results in kvrealloc(NULL, 0) returning ZEROSIZEPTR, which is treated as a success, leading to a dereference of ZEROSIZEPTR and a kernel oops.

Fix: add the missing error check after moduleextendmaxpages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.

[Sami: Corrected the analysis in the commit message.]

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

iommufd: Break the loop on failure in iommufdfaultfopsread()

On a copytouser() failure inside the inner listforeachentry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copytouser() forever, spinning the reader at 100% CPU with fault->mutex held.

Check rc after the inner loop and break the outer while as well.

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

iommufd: Set upper bounds on cache invalidation entrynum and entrylen

iommufdhwptinvalidate() takes a user-controlled entrynum and entrylen, each bounded only by U32MAX. An entrylen beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog.

A large entrynum is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel.

Cap both in the ioctl. entrylen is held under PAGESIZE, above any request struct, and entrynum under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length.

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

Input: elani2c - prevent division by zero and arithmetic underflow

The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for xtraces or ytraces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe.

Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1.

Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETPFWIDTHREDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios.

Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.

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

xfs: don't wrap around quota ids in dqiterate

LOLLM noticed that qid is an unsigned 32-bit variable. If it happens to be set to XFSDQIDMAX due to a filesystem that actually has a dquot for IDMAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64.

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

MIPS: DEC: Prevent initial console buffer from landing in XKPHYS

In 64-bit configurations calling the initial console output handler from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment and consequently so has been the buffer allocated there that is used as the argument corresponding to the %s' output conversion specifier for the firmware's printf() entry point.

This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash:

Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pidmax: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace:

Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001

---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt

KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >>

In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00.

This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started.

Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment.

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

NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR

When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:

Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]

Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.

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

kernel/fork: clear PFBLOCKTS in copyprocess()

PFBLOCKTS is only set in blktimegetns() when current->plug is non-NULL, and blkfinishplug() clears it via blkflushplug() before NULLing the plug pointer. copyprocess() breaks the invariant by inheriting PFBLOCKTS from the parent while resetting the child's plug to NULL.

Clear PFBLOCKTS alongside that assignment so callers can rely on "PFBLOCKTS set implies current->plug != NULL" and dereference current->plug unguarded.

i2c: i801: fix hardware state machine corruption in error path

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

xfs: fail recovery on a committed log item with no regions

If the first op of a transaction is a bare transaction header (len == sizeof(struct xfstransheader)), xlogrecoveraddtotrans() adds an item but no region, leaving it on ritemq with ricnt == 0 and ribuf == NULL.

The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser.

xlogrecoverreordertrans() calls ITEMTYPE() on the item, which reads (unsigned short )item->ribuf[0].iovbase and faults on the NULL ribuf. Reject it there, before the commit handlers that also read ribuf[0].

KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlogrecoverreordertrans (fs/xfs/xfslogrecover.c:1836) xlogrecovercommittrans (fs/xfs/xfslogrecover.c:2043) xlogrecoverprocessdata (fs/xfs/xfslogrecover.c:2501) xlogdorecoverypass (fs/xfs/xfslogrecover.c:3244) xlogrecover (fs/xfs/xfslogrecover.c:3493) xfslogmount (fs/xfs/xfslog.c:618) xfsmountfs (fs/xfs/xfsmount.c:1034) xfsfsfillsuper (fs/xfs/xfssuper.c:1938) vfsgettree (fs/super.c:1695) pathmount (fs/namespace.c:4161) x64sysmount (fs/namespace.c:4367)

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

irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove

The driver allocates domain generic chips using irqallocdomaingenericchips() during probe and sets up chained handlers using irqsetchainedhandleranddata(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed.

The generic chips remain on the global gclist and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash.

The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory.

Fix these issues by:

- Setting IRQDOMAINFLAGDESTROYGC flag in domain->flags, so the core code automatically removes generic chips when irqdomainremove() is called

- Clearing all chained handlers with NULL in pdcintcremove()

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

fbdev: Fix fbnewmodelist to prevent null-ptr-deref in fbvideomodetovar

info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. vartodisplay() relies on this and treats a failed fbmatchmode() as "This should not happen". fbsetvar() keeps it true by adding the mode to the list on every change, and doregisterframebuffer() does the same at registration.

storemodes() replaces the modelist from userspace. fbnewmodelist() validates the new modes but does not check that info->var still has a match. It relies on fbconnewmodelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list.

A later console takeover runs vartodisplay(), where fbmatchmode() returns NULL and leaves fbdisplay[i].mode NULL. fbconswitch() passes it to displaytovar(), and fbvideomodetovar() dereferences the NULL mode.

Keep the current mode in the list in fbnewmodelist(), the same way fbsetvar() does.

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

nfsd: reset write verifier on deferred writeback errors

nfsdvfswrite() and nfsdcommit() both call filemapcheckwberr() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commitresetwriteverifier() before returning an error.

The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32).

Add commitresetwriteverifier() calls at both filemapcheckwberr() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.

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

vcscreen: fix null-ptr-deref in vcsnotifier() during concurrent vcswrite

A KASAN null-ptr-deref was observed in vcsnotifier():

BUG: KASAN: null-ptr-deref in vcsnotifier+0x98/0x130 Read of size 2 at addr qmpcmdname: qmpcapabilities, arguments: {}

The issue is a race condition in vcswrite(). When the consolelock is temporarily dropped (to copy data from userspace), the vcdata pointer obtained from vcsvc() may become stale. After re-acquiring the lock, vcsvc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcsvc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcsscrupdated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcsnotifier dereferences param->vc).

Fix this by adding a NULL check for vc before calling vcsscrupdated().

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

media: vidtv: fix NULL pointer dereference in vidtvmuxpushsi

syzbot reported a general protection fault in vidtvpsitspsiwriteinto [1].

vidtvmuxgetpidctx() can return NULL, but vidtvmuxpushsi() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address.

The root cause is that vidtvmuxpidctxinit() does not check the return value of vidtvmuxcreatepidctxonce() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtvmuxpushsi() call then gets NULL from vidtvmuxgetpidctx() and crashes.

Fix both the root cause (add error check in vidtvmuxpidctxinit for PMT PIDs) and add defensive NULL checks in vidtvmuxpushsi for all vidtvmuxgetpidctx() calls.

[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtvmuxtick RIP: 0010:vidtvpsitspsiwriteinto+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtvpsi.c:197 Call Trace: <TASK> vidtvpsitableheaderwriteinto drivers/media/test-drivers/vidtv/vidtvpsi.c:799 [inline] vidtvpsipmtwriteinto+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtvpsi.c:1231 vidtvmuxpushsi+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtvmux.c:196 vidtvmuxtick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtvmux.c:408

agp/amd64: Fix broken error propagation in agpamd64probe()

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

mm: thp: deny THP for files on anonymous inodes

filethpenabled() incorrectly allows THP for files on anonymous inodes (e.g. guestmemfd and secretmem). These files are created via allocfilepseudo(), which does not call getwriteaccess() and leaves inode->iwritecount at 0. Combined with SISREG(inode->imode) being true, they appear as read-only regular files when CONFIGREADONLYTHPFORFS is enabled, making them eligible for THP collapse.

Anonymous inodes can never pass the inodeisopenforwrite() check since their iwritecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIGREADONLYTHPFORFS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes.

For guestmemfd, this allows khugepaged and MADVCOLLAPSE to create large folios in the page cache via the collapse path, but the guestmemfd fault handler does not support large folios. This triggers WARNONONCE(foliotestlarge(folio)) in kvmgmemfaultusermapping().

For secretmem, collapsefile() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash:

BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpyorig+0x16/0x130 Call Trace: collapsefile hpagecollapsescanfile madvisecollapse

Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports:

Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: Recovered

Check ISANONFILE(inode) in filethpenabled() to deny THP for all anonymous inode files.

drm/radeon: delete radeonfenceprocess in issignaled, no deadlock

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

gpio: rockchip: teardown bugs and resource leaks

Address several teardown issues and resource leaks in the driver's remove path and error handling:

1. Debounce clock reference leak: The debounce clock (bank->dbclk) is obtained using ofclkget() which increments the clock's reference count, but clkput() is never called. Register a devm action to cleanly release it on unbind. Note that ofclkget(..., 1) remains necessary over devmclkget() because the DT binding does not define clock-names, precluding name-based lookup.

2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove().

3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings.

[Bartosz: don't emit an error message on devres allocation failure]

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

testkprobes: clear kprobes between test runs

Running the kprobes sanity tests twice makes all tests fail and eventually crashes the kernel.

[root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobestest/run ... # Totals: pass:5 fail:0 skip:0 total:5 ok 1 kprobestest [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobestest/run ... # testkprobe: EXPECTATION FAILED at lib/tests/testkprobes.c:64 Expected 0 == registerkprobe(&kp), but registerkprobe(&kp) == -22 (0xffffffffffffffea) ... Unable to handle kernel paging request ...

The testsuite defines several kprobes and kretprobes as static variables that are preserved across test runs.

After registerkprobe and unregisterkprobe, a kprobe contains some leftover data that must be cleared before the kprobe can be registered again. The tests are setting symbolname to define the probe location. Address and flags must be cleared.

The existing code clears some of the probes between subsequent tests, but not between two test runs. The leftover data from a previous test run makes the registrations fail in the next run.

Move the cleanups for all kprobes into kprobestestinit, this function is called before each single test (including the first test of a test run).

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

phonet/pep: disable BH around forwarded skreceiveskb()

The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case releasesock() -> releasesock() drops the slock with spinunlockbh() and then calls sk->skbacklogrcv() with bottom halves enabled.

Typical skbacklogrcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pepdorcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different child socket via skreceiveskb(). That helper takes the child slock with bhlocksocknested(), which is just spinlocknested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path):

process context softirq context --------------- --------------- releasesock(listener) netifreceiveskb() releasesock() phonetrcv() spinunlockbh() skreceiveskb(listener) [BH now ENABLED] [BH already disabled] skbacklogrcv: skbacklogrcv: pepdorcv() pepdorcv() skreceiveskb(child) skreceiveskb(child) bhlocksocknested(child) bhlocksocknested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W

Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path:

WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AFPHONET/1){+.?.}-{3:3}, at: skreceiveskb+0x1cf/0x900 skreceiveskb net/core/sock.c:563 skreceiveskb include/net/sock.h:2022 [inline] pepdorcv net/phonet/pep.c:675 skbacklogrcv include/net/sock.h:1190 releasesock net/core/sock.c:3216 releasesock net/core/sock.c:3815 pepsockaccept net/phonet/pep.c:879

Wrap the forwarded skreceiveskb() in localbhdisable() / localbhenable() so the child slock is always acquired with BH off. localbhdisable() nests safely on the softirq path.

Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVELOCKING, reproducer: https://pastebin.com/A3t8xzCR