Dr. Thomas Orgis wrote on Tue, Sep 08, 2026 at 06:52:03PM +0200: Do we need an LLM agent to dig through the reports and give a summary where the vulnerabilities lie and what the mitigation would be? There are quite a few, but unlike the recent similar poc releases they were nice enough to wait a bit, so a quick look through the kernel vulns repo[1] will show that they're almost all fixed in most stable kernels.

[1] https://git.kernel.org/pub/scm/linux/security/vulns.git/

Looking at cve/published/2026/.mbox, for the last four you handpicked: === Linux-CVE-2026-43502-openSUSE-6.4.0-150600 === CVE-2026-43502: net/rds: handle zerocopy send cleanup before the message

introduced in 4.17, fixed in all stable trees === Linux-CVE-2026-52929-Ubuntu-7.0.0-28 === CVE-2026-52929: sctp: stream: fully roll back denied add-stream state

4.15+, also fixed === Linux-CVE-2026-52933-Fedora-6.19.10-300 === CVE-2026-52933: iouring/poll: fix signed comparison in iopollgetownership()

6.1+, also fixed === Linux-CVE-2026-72137-ubuntu-7.0.0-28 === CVE-2026-72137: xfrm: natkeepalive: avoid double free on send error

6.11+, also fixed

FWIW, the ones that aren't fixed yet are: - 'CVE-2026-72255: netfilter: nfqueue: pin bridge device while NFQUEUE holds fake dst' was missing 5.10, someone already sent a patch

- 'CVE-2026-43042: mpls: add seqcount to protect the platformlabel{,s} pair' is missing 4.1(so 5.10) ~ 6.18 (only 6.19+ fixed); I tried backporting it but that code changed too much, I'm not sure the Fixes commit was correctly identified but conversely the prereqs added locks so one could argue that older code was maybe even worse? I'm not sure, but MPLS is low level network stuff and likely needs a net namespace as your grep showed (there are multiple mpls modules, this CVE apparently affects the mplsrouter module looking at which files the fix touched)

- 'CVE-2026-31678: openvswitch: defer tunnel netdevput to RCU release' is missing 4.3(5.10) ~ 6.0 (6.1+ fixed). OVS is disabled for our kernel so I didn't look deeper but openvswitch is likely to be built as a module and definitely needs network namespaces.

Cheers(?), -- Dominique Martinet | Asmadeus

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

posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()

If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().

If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.

Add the tsk->exitstate check into runposixcputimers() to fix this.

This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.

Do we need an LLM agent to dig through the reports and give a summary where the vulnerabilities lie and what the mitigation would be?

Am Mon, 7 Sep 2026 20:29:16 -0700 schrieb Yuan Tan <yuant () nebusec ai>: We found a Linux kernel local privilege escalation vulnerability in the RDS zerocopy send path, tracked as CVE-2026-43502. We call the exploit ZcopyReaper.

CONFIGINET=y   CONFIGAIO=y   CONFIGRDS=y or m   CONFIGRDSTCP=y or m Good. Another obscure networking feature that I didn't know of and which yields system exploitation. Locking kernel module loading after boot has paid of many times now! In addition to CVE-2026-43502, there are 20 other Linux bugs that have been confirmed to be exploitable, with public exploits available: Now, need I worry or not? What can I do? I checked out the repo and did some guessing:

$ for f in Linux-CVE-2026-; do echo === $f ===; (cd $f && find . -type f |xargs grep unshare); done < === Linux-CVE-2026-23274-kernelCTF === ./exploit.c:void unsharesetup(); ./exploit.c: unsharesetup(); ./exploit.c:void unsharesetup() { ./exploit.c: SYSCHK(unshare(CLONENEWUSER)); ./exploit.c: SYSCHK(unshare(CLONENEWNET | CLONENEWNS)); ./exploit.c: unsharesetup(); ./exploit.c: unsharesetup();

Needs network namespaces.

=== Linux-CVE-2026-31659-Arch-6.19.10 === ./exploit.c: if (unshare(CLONENEWUSER | CLONENEWNET) < 0) ./exploit.c: die("unshare(CLONENEWUSER|CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-31678-Fedora-6.19.10-300 === ./exploit.c: if (unshare(CLONENEWNS) < 0) ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET)); ./exploit-v104-crosscpu-flush-trace.c: if (unshare(CLONENEWUSER) < 0) ./exploit-v104-crosscpu-flush-trace.c: die("unshare(CLONENEWUSER)"); ./exploit-v104-crosscpu-flush-trace.c: if (unshare(CLONENEWNET) < 0) ./exploit-v104-crosscpu-flush-trace.c: die("unshare(CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-43042-Debian-6.12.101 === ./utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-43501-kernelCTF === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare(CLONENEWUSER)"); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare(CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-43502-openSUSE-6.4.0-150600 ===

??????

=== Linux-CVE-2026-52912-Fedora-6.19.10-300 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare(CLONENEWUSER)"); ./exploit.c: if (unshare(CLONENEWNET | CLONENEWNS) < 0) ./exploit.c: die("unshare(CLONENEWNET|CLONENEWNS)"); ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52923-RHEL-6.12.0-211.7.3.el102 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare user"); ./exploit.c: if (unshare(CLONENEWIPC) < 0) ./exploit.c: die("unshare ipc"); ./exploit.c: if (unshare(CLONENEWIPC) < 0) ./exploit.c: die("unshare(victim ipc)"); ./exploit.c: if (unshare(CLONENEWIPC) < 0) ./exploit.c: die("unshare(trigger ipc)"); ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52924-Arch-6.19.10 === ./trigger.c: if (unshare(CLONENEWUSER | CLONENEWNET) < 0) ./trigger.c: die("unshare user+net"); ./utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52924-ubuntu-7.0.0-28 === ./trigger.c: if (unshare(CLONENEWUSER) < 0) ./trigger.c: die("unshare user"); ./trigger.c: if (unshare(CLONENEWNET) < 0) ./trigger.c: die("unshare net"); ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-52929-Ubuntu-7.0.0-28 ===

????

=== Linux-CVE-2026-52933-Fedora-6.19.10-300 ===

????

=== Linux-CVE-2026-63834-Arch-6.19.10 === ./kernelsnitch/utils.h: SYSCHK(unshare(CLONENEWUSER | CLONENEWNET));

Needs network namespaces.

=== Linux-CVE-2026-68162-Ubuntu-7.0.0-28 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare user: %s", strerror(errno)); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare net: %s", strerror(errno)); ./exploit.c: if (unshare(CLONENEWNS) < 0) ./exploit.c: die("unshare mount namespace: %s", strerror(errno));

Needs network namespaces.

=== Linux-CVE-2026-68376-Ubuntu-7.0.0-30 === ./exploit.c: if (unshare(CLONENEWUSER)) ./exploit.c: die("unshare user"); ./exploit.c: if (unshare(CLONENEWNET)) ./exploit.c: die("unshare net");

Needs network namespaces.

=== Linux-CVE-2026-72137-ubuntu-7.0.0-28 ===

????

=== Linux-CVE-2026-72255-Ubuntu-7.0.0-28 === ./trigger.c: if (unshare(CLONENEWUSER) < 0) ./trigger.c: die("unshare(CLONENEWUSER)"); ./trigger.c: if (unshare(CLONENEWNET | CLONENEWNS) < 0) ./trigger.c: die("unshare(CLONENEWNET|CLONENEWNS)"); ./trigger.c: if (patternindex && unshare(CLONENEWNET) < 0) ./trigger.c: die("unshare(next network namespace)");

Needs network namespaces.

=== Linux-CVE-2026-74480-RHEL-6.12.0-211.7.3.el102 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare userns"); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare netns");

Needs network namespaces.

=== Linux-CVE-2026-74581-Debian-6.12.101 === ./exploit.c: if (unshare(CLONENEWUSER) < 0) ./exploit.c: die("unshare user"); ./exploit.c: if (unshare(CLONENEWNET) < 0) ./exploit.c: die("unshare net");

Needs network namespaces.

=== Linux-CVE-2026-74597-Centos-10-6.12.0-264 === ./exploit.c: if (unshare(CLONENEWUSER)) ./exploit.c: die("unshare(CLONENEWUSER)"); ./exploit.c: if (unshare(CLONENEWNET)) ./exploit.c: die("unshare(CLONENEWNET)");

Needs network namespaces.

=== Linux-CVE-2026-80714-Debian-6.12.101 === ./exploit.c: CHECK(unshare(CLONENEWUSER), "unshare user"); ./exploit.c: CHECK(unshare(CLONENEWNET), "unshare net");

Needs network namespaces.

So this drives home the point that (unprivileged) network namespaces are something that will stay forbidden on my systems. What a can of worms that is!

But there is a number of exploits that get away without that:

=== Linux-CVE-2026-43502-openSUSE-6.4.0-150600 === === Linux-CVE-2026-52929-Ubuntu-7.0.0-28 === === Linux-CVE-2026-52933-Fedora-6.19.10-300 === === Linux-CVE-2026-72137-ubuntu-7.0.0-28 ===

Someone got the time to dig out what those are about?

Alrighty then,

Thomas

-- Dr. Thomas Orgis HPC @ Universität Hamburg

crypto: algifaead - Revert to operating out-of-place

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

proc: protect ptracemayaccess() with execupdatelock (FD links)

procpidgetlink() and procpidreadlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways.

To fix it, pass the task to the ->procgetlink() handler, and instead of procfdaccessallowed(), introduce a new helper callprocgetlink() that looks up and locks the task, does the access check, and calls ->procgetlink().

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

smb: client: harden POSIX SID length parsing

posixinfosidsize() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.

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

net, bpf: check master for NULL in xdpmasterredirect()

xdpmasterredirect() dereferences the result of netdevmasterupperdevgetrcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency.

The reach guard only checks netifisbondslave(). On bond slave release bondupperdevunlink() drops the upper-master adjacency before clearing IFFSLAVE, so an XDPTX reaching xdpmasterredirect() in that window still passes netifisbondslave() while master is already NULL, and faults on master->flags at offset 0xb0:

BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdpmasterredirect (net/core/filter.c:4432) Call Trace: xdpmasterredirect (net/core/filter.c:4432) bpfprogrungenericxdp (include/net/xdp.h:700) doxdpgeneric (net/core/dev.c:5608) netifreceiveskbonecore (net/core/dev.c:6204) processbacklog (net/core/dev.c:6319) napipoll (net/core/dev.c:7729) netrxaction (net/core/dev.c:7792) handlesoftirqs (kernel/softirq.c:622) devqueuexmit (include/linux/bottomhalf.h:33) packetsendmsg (net/packet/afpacket.c:3082) syssendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt

The missing check dates back to the original code; commit 1921f91298d1 ("net, bpf: fix null-ptr-deref in xdpmasterredirect() for down master") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.

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

ipv4: igmp: remove multicast group from hash table on device destruction

When a device is destroyed under RTNL, ipmcdestroydev() iterates through the multicast list and calls ipmaput() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mchash).

Since the device remains published in dev->ipptr until after ipmcdestroydev() completes, concurrent RCU readers traversing mchash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs.

Fix this by unlinking the multicast group from mchash using ipmchashremove() before scheduling it for reclamation.

BUG: KASAN: slab-use-after-free in ipcheckmcrcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276

Call Trace: <IRQ> dumpstacklvl+0x67/0x90 printreport+0x175/0x7c0 kasanreport+0x147/0x180 ipcheckmcrcu+0x149/0x3f0 udpv4earlydemux+0x36d/0x12d0 iprcvfinishcore+0xb8b/0x1390 iprcvfinish+0x54/0x120 NFHOOK+0x213/0x2b0 netifreceiveskb+0x126/0x340 processbacklog+0x4f2/0xf00 napipoll+0x92/0x2c0 netrxaction+0x583/0xc60 handlesoftirqs+0x236/0x7f0 dosoftirq+0x57/0x80 </IRQ>

Allocated by task 2239: kasansavetrack+0x3e/0x80 kasankmalloc+0x72/0x90 ipmcincgroup+0x31a/0xa40 ipmcjoingroup+0x334/0x3f0 doipsetsockopt+0x16fa/0x2010 ipsetsockopt+0x3f/0x90 dosocksetsockopt+0x1ad/0x300

Freed by task 0: kasansavetrack+0x3e/0x80 kasansavefreeinfo+0x40/0x50 kasanslabfree+0x3a/0x60 rcufreesheafprepare+0xd4/0x220 rcufreesheaf+0x36/0x190 rcucore+0x8d9/0x12f0 handlesoftirqs+0x236/0x7f0

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

iouring/io-wq: re-check IOWQBITEXIT for each linked work item

commit 10dc95939817 ("iouring/io-wq: check IOWQBITEXIT inside work run loop") fixed the obvious case where ioworkerhandlework() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.

ioworkerhandlework() now re-checks IOWQBITEXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If iowqexitstart() sets IOWQBITEXIT after the first linked item has started, the remaining linked items can still reuse stale dokill = false, skip IOWQWORKCANCEL, and continue running after exit has begun.

Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.

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

ipv6: Fix null-ptr-deref in fib6nhmtuchange().

fib6nhmtuchange() re-fetches idev via in6devget(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconfifdown() clears dev->ip6ptr with RCUINITPOINTER() after rt6disableip() has released tb6lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6mtuchangeroute() guards its own in6devget(), but this re-fetch is unguarded; nexthop-backed routes survive addrconfifdown()'s flush, so the walk still reaches it after ip6ptr is nulled.

Return 0 when idev is NULL, matching rt6mtuchangeroute() and the fib6mtu() fix in commit 5ad509c1fdad ("ipv6: Fix null-ptr-deref in fib6mtu().").

Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6nhmtuchange+0x203/0x990 rt6mtuchangeroute+0x141/0x1d0 fib6cleanall+0xd0/0x160 rt6mtuchange+0xb4/0x100 ndiscrouterdiscovery+0x24b5/0x2cb0 icmpv6rcv+0x12e9/0x1710 ipv6rcv+0x39b/0x410

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

isofs: bound Rock Ridge symlink components to the SL record

getsymlinkchunk() and the SL handling in parserockridgeinodeinternal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and getsymlinkchunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it.

A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; getsymlinkchunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory.

ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAPSYSADMIN - so the record contents are attacker-controlled.

Reject any component that does not fit in the remaining record bytes before using it. In getsymlinkchunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parserockridgeinodeinternal() stop the inode-size walk.

block: Avoid mounting the bdev pseudo-filesystem in userspace

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

signal: clear JOBCTLPENDINGMASK for caller in zapotherthreads()

When a multi-threaded process receives a stop signal (e.g., SIGSTOP), dosignalstop() sets JOBCTLSTOPPENDING and JOBCTLSTOPCONSUME on all threads and sets signal->groupstopcount to the number of threads. If one of the threads concurrently calls execve(), dethread() invokes zapotherthreads() to kill all other threads. zapotherthreads() aborts the pending group stop by resetting signal->groupstopcount to 0 and clears the JOBCTLPENDINGMASK for all other threads. However, it fails to clear the job control flags for the calling thread.

When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTLSTOPPENDING flag, it calls dosignalstop(), which invokes taskparticipategroupstop(). Since JOBCTLSTOPCONSUME is still set, it attempts to decrement the already-zero signal->groupstopcount, triggering a warning:

sig->groupstopcount == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 taskparticipategroupstop+0x215/0x2d0 Call Trace: <TASK> dosignalstop+0x3be/0x5c0 kernel/signal.c:2619 getsignal+0xa8c/0x1330 kernel/signal.c:2884 archdosignalorrestart+0xbc/0x840 arch/x86/kernel/signal.c:337 exittousermodeloop+0x8c/0x4d0 kernel/entry/common.c:98 dosyscall64+0x33e/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix this race condition by clearing the JOBCTLPENDINGMASK for the calling thread in zapotherthreads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zapprocess() and completesignal(), which correctly clear these flags for all threads including the current one.

i2c: core: fix adapter registration race

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

mailbox: add sanity check for channel array

Fail gracefully if there is no channel array attached to the mailbox controller. Otherwise the later dereference will cause an OOPS which might not be seen because mailbox controllers might instantiate very early. Remove the comment explaining the obvious while here.

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

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

pnfs/flexfiles: Fix memory leak in nfs4ffallocdeviceidnode()

In nfs4ffallocdeviceidnode(), if the allocation for dsversions fails, the function jumps to the outscratch label without freeing the already allocated dsaddrs list, leading to a memory leak.

Fix this by jumping to the outerrdraindsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.

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

net: hns3: using the numtqps in the vf driver to apply for resources

Currently, hdev->htqp is allocated using hdev->numtqps, and kinfo->tqp is allocated using kinfo->numtqps. However, kinfo->numtqps is set to min(newtqps, hdev->numtqps); Therefore, kinfo->numtqps may be smaller than hdev->numtqps, which causes some hdev->htqp[i] to remain uninitialized in hclgevfknicsetup().

Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->numtqps, ensuring that the lengths of hdev->htqp and kinfo->tqp are consistent and that all elements are properly initialized.

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

nvme: nvme-fc: Ensure ->ioerrwork is cancelled in nvmefcdeletectrl()

nvmefcdeleteassocation() waits for pending I/O to complete before returning, and an error can cause ->ioerrwork to be queued after cancelworksync() had been called. Move the call to cancelworksync() to be after nvmefcdeleteassociation() to ensure ->ioerrwork is not running when the nvmefcctrl object is freed. Otherwise the following can occur:

[ 1135.911754] listdel corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/listdebug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:listdelentryvalidorreport.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.067540] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.071898] ? movelinkedworks+0x4a/0xa0 [ 1136.075998] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.081744] ? diebody.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? dotrap+0xca/0x110 [ 1136.091789] ? doerrortrap+0x65/0x80 [ 1136.095543] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.101289] ? excinvalidop+0x50/0x70 [ 1136.105127] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.110874] ? asmexcinvalidop+0x1a/0x20 [ 1136.115059] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.120806] movelinkedworks+0x4a/0xa0 [ 1136.124733] workerthread+0x216/0x3a0 [ 1136.128485] ? pfxworkerthread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? pfxkthread+0x10/0x10 [ 1136.139657] retfromfork+0x31/0x50 [ 1136.143236] ? pfxkthread+0x10/0x10 [ 1136.146988] retfromforkasm+0x1a/0x30 [ 1136.150915] </TASK>

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

nbd: restrict sockets to TCP and UDP

Recently, syzbot started to abuse NBD with all kinds of sockets.

Commit cf1b2326b734 ("nbd: verify socket is supported during setup") made sure the socket supported a shutdown() method.

Explicitely accept TCP and UNIX stream sockets.

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

tcp: Clear tcpsk(sk)->fastopenrsk in tcpdisconnect().

syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCPESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:

1. accept() 2. connect(AFUNSPEC) 3. connect() to another destination

As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCPCLOSE and makes connect() possible, which restarts timers.

Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopenrsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.

Let's call reqskfastopenremove() in tcpdisconnect().

[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcptimer.c:542 tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>

cgroup: split cgroupdestroywq into 3 workqueues

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:

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

fs: Prevent file descriptor table allocations exceeding INTMAX

bpf: Forget ranges when refining tnum after JSET

fs/buffer: fix use-after-free when call bhread() helper

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:

rcu/nocb: Fix possible invalid rdp's->nocbcbkthread pointer access

In the preparation stage of CPU online, if the corresponding the rdp's->nocbcbkthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocbcbkthread pointer, but this rdp's->nocbgprdp and rdp's->rdpgp->nocbgpkthread is still valid.

This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthreadunpark() will access invalid rdp's->nocbcbkthread pointer.

This commit therefore use rdp's->nocbgpkthread instead of rdpgp's->nocbgpkthread for safety check.

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.