OESA-2026-1864

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

f2fs: fix to detect potential corrupted nid in freenidlist

As reported, on-disk footer.ino and footer.nid is the same and out-of-range, let's add sanity check on f2fsallocnid() to detect any potential corruption in freenidlist.(CVE-2025-68315)

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

ntfs3: Fix uninit buffer allocated by __getname()

Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.(CVE-2025-68727)

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

netfilter: nftables: fix use-after-free in nftables_addchain()

nftablesaddchain() publishes the chain to table->chains via listaddtailrcu() (in nftchainadd()) before registering hooks. If nftablesregisterhook() then fails, the error path calls nftchaindel() (listdelrcu()) followed by nftableschain_destroy() with no RCU grace period in between.

This creates two use-after-free conditions:

1) Control-plane: nftablesdumpchains() traverses table->chains under rcuread_lock(). A concurrent dump can still be walking the chain when the error path frees it.

2) Packet path: for NFPROTOINET, nfregisternethook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nftdochain() via the transient IPv4 hook can still be dereferencing chain->blobgenX when the error path frees the chain.

Add synchronizercu() between nftchain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.(CVE-2026-23231)

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

tls: Fix race condition in tlsswcancelworktx()

This issue was discovered during a code audit.

After canceldelayedworksync() is called from tlsskprotoclose(), txworkhandler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the txworkhandler() worker may dereference a freed TLS object.

The following is a simple race scenario:

      cpu0                         cpu1

tlsskprotoclose() tlsswcancelworktx() tlswritespace() tlsswwritespace() if (!testandsetbit(BITTXSCHEDULED, &txctx->txbitmask)) setbit(BITTXSCHEDULED, &ctx->txbitmask); canceldelayedworksync(&ctx->txwork.work); scheduledelayedwork(&txctx->tx_work.work, 0);

To prevent this race condition, canceldelayedworksync() is replaced with disabledelayedworksync().(CVE-2026-23240)

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

net/sched: act_gate: snapshot parameters with RCU on replace

The gate action can be replaced while the hrtimer callback or dump path is walking the schedule list.

Convert the parameters to an RCU-protected snapshot and swap updates under tcflock, freeing the previous snapshot via callrcu(). When REPLACE omits the entry list, preserve the existing schedule so the effective state is unchanged.(CVE-2026-23245)

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

net: gro: fix outer network offset

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

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

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

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

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

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

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

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

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

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

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

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

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

Many thanks to Dong Chenchen for providing a repro.(CVE-2026-23255)

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

net/sched: Only allow act_ct to bind to clsact/ingress qdiscs and shared blocks

As Paolo said earlier [1]:

"Since the blamed commit below, classify can return TCACTCONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet."

actct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TCACTCONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing actct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach act_ct to egress (albeit only with clsact).

[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/ [2] https://lore.kernel.org/netdev/(CVE-2026-23270)

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

netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels

IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer.

If the label was created first by revision 1 with XTIDLETIMERALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes modtimer() on an uninitialized timerlist, triggering debugobjects warnings and possible panic when paniconwarn=1.

Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.(CVE-2026-23274)

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

net: add xmit recursion limit to tunnel xmit functions

Tunnel xmit functions (iptunnelxmit, ip6tunnelxmit) lack their own recursion limit. When a bond device in broadcast mode has GRE tap interfaces as slaves, and those GRE tunnels route back through the bond, multicast/broadcast traffic triggers infinite recursion between bondxmitbroadcast() and iptunnelxmit()/ip6tnlxmit(), causing kernel stack overflow.

The existing XMITRECURSIONLIMIT (8) in the no-qdisc path is not sufficient because tunnel recursion involves route lookups and full IP output, consuming much more stack per level. Use a lower limit of 4 (IPTUNNELRECURSION_LIMIT) to prevent overflow.

Add recursion detection using devxmitrecursion helpers directly in iptunnelxmit() and ip6tunnelxmit() to cover all IPv4/IPv6 tunnel paths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).

Move devxmitrecursion helpers from net/core/dev.h to public header include/linux/netdevice.h so they can be used by tunnel code.

BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160 Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11 Workqueue: mld mldifcwork Call Trace: <TASK> __buildflowkey.constprop.0 (net/ipv4/route.c:515) iprtupdatepmtu (net/ipv4/route.c:1073) iptunnelxmit (net/ipv4/iptunnelcore.c:84) iptunnelxmit (net/ipv4/iptunnel.c:847) gretapxmit (net/ipv4/ipgre.c:779) devhardstartxmit (net/core/dev.c:3887) schdirectxmit (net/sched/schgeneric.c:347) __devqueuexmit (net/core/dev.c:4802) bonddevqueuexmit (drivers/net/bonding/bondmain.c:312) bondxmitbroadcast (drivers/net/bonding/bondmain.c:5279) bondstartxmit (drivers/net/bonding/bondmain.c:5530) devhardstart_xmit (net/core/dev.c:3887) __devqueuexmit (net/core/dev.c:4841) ipfinishoutput2 (net/ipv4/ipoutput.c:237) ipoutput (net/ipv4/ipoutput.c:438) iptunnelxmit (net/ipv4/iptunnelcore.c:86) gretapxmit (net/ipv4/ipgre.c:779) devhardstartxmit (net/core/dev.c:3887) schdirectxmit (net/sched/sch_generic.c:347) __devqueuexmit (net/core/dev.c:4802) bonddevqueuexmit (drivers/net/bonding/bondmain.c:312) bondxmitbroadcast (drivers/net/bonding/bondmain.c:5279) bondstartxmit (drivers/net/bonding/bondmain.c:5530) devhardstart_xmit (net/core/dev.c:3887) __devqueuexmit (net/core/dev.c:4841) ipfinishoutput2 (net/ipv4/ipoutput.c:237) ipoutput (net/ipv4/ipoutput.c:438) iptunnelxmit (net/ipv4/iptunnelcore.c:86) iptunnelxmit (net/ipv4/iptunnel.c:847) gretapxmit (net/ipv4/ipgre.c:779) devhardstartxmit (net/core/dev.c:3887) schdirectxmit (net/sched/schgeneric.c:347) __devqueuexmit (net/core/dev.c:4802) bond_devqueuexmit (drivers/net/bonding/bondmain.c:312) bondxmitbroadcast (drivers/net/bonding/bondmain.c:5279) bondstartxmit (drivers/net/bonding/bondmain.c:5530) devhardstartxmit (net/core/dev.c:3887) __devqueuexmit (net/core/dev.c:4841) mldsendpack mldifcwork processonework workerthread </TASK>(CVE-2026-23276)

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

net/sched: teql: fix NULL pointer dereference in iptunnel_xmit on TEQL slave xmit

teqlmasterxmit() calls netdevstartxmit(skb, slave) to transmit through slave devices, but does not update skb->dev to the slave device beforehand.

When a gretap tunnel is a TEQL slave, the transmit path reaches iptunnelxmit() which saves dev = skb->dev (still pointing to teql0 master) and later calls iptunnelxmitstats(dev, pktlen). This function does:

get_cpu_ptr(dev->tstats)

Since teqlmastersetup() does not set dev->pcpustattype to NETDEVPCPUSTATTSTATS, the core network stack never allocates tstats for teql0, so dev->tstats is NULL. getcpu_ptr(NULL) computes NULL + __percpuoffset[cpu], resulting in a page fault.

BUG: unable to handle page fault for address: ffff8880e6659018 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 68bc067 P4D 68bc067 PUD 0 Oops: Oops: 0002 [#1] SMP KASAN PTI RIP: 0010:iptunnelxmit (./include/net/iptunnels.h:664 net/ipv4/iptunnelcore.c:89) Call Trace: <TASK> iptunnelxmit (net/ipv4/iptunnel.c:847) __grexmit (net/ipv4/ipgre.c:478) gretapxmit (net/ipv4/ipgre.c:779) teqlmasterxmit (net/sched/schteql.c:319) devhardstartxmit (net/core/dev.c:3887) schdirectxmit (net/sched/schgeneric.c:347) __devqueuexmit (net/core/dev.c:4802) neighdirectoutput (net/core/neighbour.c:1660) ipfinishoutput2 (net/ipv4/ip_output.c:237) __ipfinishoutput.part.0 (net/ipv4/ipoutput.c:315) ipmcoutput (net/ipv4/ipoutput.c:369) ipsendskb (net/ipv4/ipoutput.c:1508) udpsendskb (net/ipv4/udp.c:1195) udpsendmsg (net/ipv4/udp.c:1485) inetsendmsg (net/ipv4/afinet.c:859) _syssendto (net/socket.c:2206)

Fix this by setting skb->dev = slave before calling netdevstartxmit(), so that tunnel xmit functions see the correct slave device with properly allocated tstats.(CVE-2026-23277)

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

netfilter: nf_tables: always walk all pending catchall elements

During transaction processing we might have more than one catchall element: 1 live catchall element and 1 pending element that is coming as part of the new batch.

If the map holding the catchall elements is also going away, its required to toggle all catchall elements and not just the first viable candidate.

Otherwise, we get: WARNING: ./include/net/netfilter/nftables.h:1281 at nftdatarelease+0xb7/0xe0 [nftables], CPU#2: nft/1404 RIP: 0010:nftdatarelease+0xb7/0xe0 [nf_tables] [..] _nftsetelemdestroy+0x106/0x380 [nftables] nftablesabortrelease+0x348/0x8d0 [nftables] nftablesabort+0xcf2/0x3ac0 [nftables] nfnetlinkrcvbatch+0x9c9/0x20e0 ..

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

net: vxlan: fix nd_tbl NULL dereference when IPv6 is disabled

When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. If an IPv6 packet is injected into the interface, routeshortcircuit() is called and a NULL pointer dereference happens on neigh_lookup().

BUG: kernel NULL pointer dereference, address: 0000000000000380 Oops: Oops: 0000 [#1] SMP NOPTI [...] RIP: 0010:neighlookup+0x20/0x270 [...] Call Trace: <TASK> vxlanxmit+0x638/0x1ef0 [vxlan] devhardstart_xmit+0x9e/0x2e0 __devqueuexmit+0xbee/0x14e0 packet_sendmsg+0x116f/0x1930 __sys_sendto+0x1f5/0x200 __x64syssendto+0x24/0x30 dosyscall64+0x12f/0x1590 entrySYSCALL64afterhwframe+0x76/0x7e

Fix this by adding an early check on routeshortcircuit() when protocol is ETHPIPV6. Note that ipv6mod_enabled() cannot be used here because VXLAN can be built-in even when IPv6 is built as a module.(CVE-2026-23293)

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

net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop

When a standalone IPv6 nexthop object is created with a loopback device (e.g., "ip -6 nexthop add id 100 dev lo"), fib6nhinit() misclassifies it as a reject route. This is because nexthop objects have no destination prefix (fcdst=::), causing fib6isreject() to match any loopback nexthop. The reject path skips fibnhcommoninit(), leaving nhcpcpurth_output unallocated. If an IPv4 route later references this nexthop, __mkrouteoutput() dereferences NULL nhcpcpurthoutput and panics.

Simplify the check in fib6nhinit() to only match explicit reject routes (RTFREJECT) instead of using fib6isreject(). The loopback promotion heuristic in fib6isreject() is handled separately by ip6routeinfocreate_nh(). After this change, the three cases behave as follows:

1. Explicit reject route ("ip -6 route add unreachable 2001:db8::/64"): RTFREJECT is set, enters reject path, skips fibnhcommoninit(). No behavior change.

2. Implicit loopback reject route ("ip -6 route add 2001:db8::/32 dev lo"): RTFREJECT is not set, takes normal path, fibnhcommoninit() is called. ip6routeinfocreatenh() still promotes it to reject afterward. nhcpcpurth_output is allocated but unused, which is harmless.

3. Standalone nexthop object ("ip -6 nexthop add id 100 dev lo"): RTFREJECT is not set, takes normal path, fibnhcommoninit() is called. nhcpcpurth_output is properly allocated, fixing the crash when IPv4 routes reference this nexthop.(CVE-2026-23300)

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

net: annotate data-races around sk->sk_{dataready,writespace}

skmsg (and probably other layers) are changing these pointers while other cpus might read them concurrently.

Add corresponding READONCE()/WRITEONCE() annotations for UDP, TCP and AF_UNIX.(CVE-2026-23302)

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

smb: client: Don't log plaintext credentials in cifssetcifscreds

When debug logging is enabled, cifssetcifscreds() logs the key payload and exposes the plaintext username and password. Remove the debug log to avoid exposing credentials.(CVE-2026-23303)

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

ipv6: fix NULL pointer deref in ip6rtgetdevrcu()

l3mdevmasterdevrcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6rtpcpualloc() -> ip6rtgetdevrcu() with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on device with address").

KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6rtpcpualloc (net/ipv6/route.c:1418) Call Trace: ip6polroute (net/ipv6/route.c:2318) fib6rulelookup (net/ipv6/fib6rules.c:115) ip6routeoutputflags (net/ipv6/route.c:2607) vrfprocessv6outbound (drivers/net/vrf.c:437)

I was tempted to rework the un-slaving code to clear the flag first and insert synchronizercu() before we remove the upper. But looks like the explicit fallback to loopbackdev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.(CVE-2026-23304)

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

bpf/bonding: reject vlan+srcmac xmithashpolicy change when XDP is loaded

bondoptionmodeset() already rejects mode changes that would make a loaded XDP program incompatible via bondxdpcheck(). However, bondoptionxmithashpolicyset() has no such guard.

For 802.3ad and balance-xor modes, bondxdpcheck() returns false when xmithashpolicy is vlan+srcmac, because the 802.1q payload is usually absent due to hardware offload. This means a user can:

1. Attach a native XDP program to a bond in 802.3ad/balance-xor mode with a compatible xmithashpolicy (e.g. layer2+3).
2. Change xmithashpolicy to vlan+srcmac while XDP remains loaded.

This leaves bond->xdpprog set but bondxdpcheck() now returning false for the same device. When the bond is later destroyed, devxdpuninstall() calls bondxdpset(dev, NULL, NULL) to remove the program, which hits the bondxdp_check() guard and returns -EOPNOTSUPP, triggering:

WARNON(devxdpinstall(dev, mode, bpfop, NULL, 0, NULL))

Fix this by rejecting xmithashpolicy changes to vlan+srcmac when an XDP program is loaded on a bond in 802.3ad or balance-xor mode.

commit 39a0876d595b ("net, bonding: Disallow vlan+srcmac with XDP") introduced bondxdpcheck() which returns false for 802.3ad/balance-xor modes when xmithashpolicy is vlan+srcmac. The check was wired into bondxdpset() to reject XDP attachment with an incompatible policy, but the symmetric path -- preventing xmithashpolicy from being changed to an incompatible value after XDP is already loaded -- was left unguarded in bondoptionxmithashpolicy_set().

Note: commit 094ee6017ea0 ("bonding: check xdp prog when set bond mode") later added a similar guard to bondoptionmodeset(), but bondoptionxmithashpolicyset() remained unprotected.(CVE-2026-23310)

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

mptcp: pm: in-kernel: always mark signal+subflow endp as used

Syzkaller managed to find a combination of actions that was generating this warning:

msk->pm.localaddrused == 0 WARNING: net/mptcp/pm_kernel.c:1071 at __marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline], CPU#1: syz.2.17/961 WARNING: net/mptcp/pmkernel.c:1071 at mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pm_kernel.c:1210, CPU#1: syz.2.17/961 Modules linked in: CPU: 1 UID: 0 PID: 961 Comm: syz.2.17 Not tainted 6.19.0-08368-gfafda3b4b06b #22 PREEMPT(full) Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.17.0-debian-1.17.0-1build1 04/01/2014 RIP: 0010:__marksubflowendpavailable net/mptcp/pmkernel.c:1071 [inline] RIP: 0010:mptcpnlremovesubflowandsignaladdr net/mptcp/pmkernel.c:1103 [inline] RIP: 0010:mptcppmnldeladdrdoit+0x81d/0x8f0 net/mptcp/pmkernel.c:1210 Code: 89 c5 e8 46 30 6f fe e9 21 fd ff ff 49 83 ed 80 e8 38 30 6f fe 4c 89 ef be 03 00 00 00 e8 db 49 df fe eb ac e8 24 30 6f fe 90 <0f> 0b 90 e9 1d ff ff ff e8 16 30 6f fe eb 05 e8 0f 30 6f fe e8 9a RSP: 0018:ffffc90001663880 EFLAGS: 00010293 RAX: ffffffff82de1a6c RBX: 0000000000000000 RCX: ffff88800722b500 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880158b22d0 R08: 0000000000010425 R09: ffffffffffffffff R10: ffffffff82de18ba R11: 0000000000000000 R12: ffff88800641a640 R13: ffff8880158b1880 R14: ffff88801ec3c900 R15: ffff88800641a650 FS: 00005555722c3500(0000) GS:ffff8880f909d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f66346e0f60 CR3: 000000001607c000 CR4: 0000000000350ef0 Call Trace: <TASK> genlfamilyrcvmsgdoit+0x117/0x180 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x3a8/0x3f0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x16d/0x240 net/netlink/afnetlink.c:2550 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x3e9/0x4c0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x4aa/0x5b0 net/netlink/afnetlink.c:1894 socksendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0xc9/0xf0 net/socket.c:742 ____sys_sendmsg+0x272/0x3b0 net/socket.c:2592 ___sys_sendmsg+0x2de/0x320 net/socket.c:2646 __sys_sendmsg net/socket.c:2678 [inline] __dosyssendmsg net/socket.c:2683 [inline] __sesyssendmsg net/socket.c:2681 [inline] _x64syssendmsg+0x110/0x1a0 net/socket.c:2681 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x143/0x440 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f66346f826d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc83d8bdc8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6634985fa0 RCX: 00007f66346f826d RDX: 00000000040000b0 RSI: 0000200000000740 RDI: 0000000000000007 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6634985fa8 R13: 00007f6634985fac R14: 0000000000000000 R15: 0000000000001770 </TASK>

The actions that caused that seem to be:

• Set the MPTCP subflows limit to 0
• Create an MPTCP endpoint with both the 'signal' and 'subflow' flags
• Create a new MPTCP connection from a different address: an ADD_ADDR linked to the MPTCP endpoint will be sent ('signal' flag), but no subflows is initiated ('subflow' flag)
• Remove the MPTCP endpoint

---truncated---(CVE-2026-23321)

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

xdp: produce a warning when calculated tailroom is negative

Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpfxdpfragsincreasetail(), clearly expects a truesize.

Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDPADJUSTTAILGROWMULTIBUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->fragsize was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset.

We are supposed to return -EINVAL and be done with it in such case, but due to tailroom being stored as an unsigned int, it is reported to be somewhere near UINT_MAX, resulting in a tail being grown, even if the requested offset is too much (it is around 2K in the abovementioned test). This later leads to all kinds of unspecific calltraces.

[ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] [ 7340.340300] likely on CPU 6 (core 0, socket 6) [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe [ 7340.340888] likely on CPU 3 (core 0, socket 3) [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookupswapcgroupid+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] <TASK> [ 7340.422309] ? softleaffrompte+0x77/0xa0 [ 7340.422855] swapptebatch+0xa7/0x290 [ 7340.423363] zapnonpresentptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zappterange+0x281/0x580 [ 7340.424607] zappmdrange.isra.0+0xc9/0x240 [ 7340.425177] unmappagerange+0x24d/0x420 [ 7340.425714] unmapvmas+0xa1/0x180 [ 7340.426185] exit_mmap+0xe1/0x3b0 [ 7340.426644] _mmput+0x41/0x150 [ 7340.427098] exitmm+0xb1/0x110 [ 7340.427539] doexit+0x1b2/0x460 [ 7340.427992] dogroupexit+0x2d/0xc0 [ 7340.428477] getsignal+0x79d/0x7e0 [ 7340.428957] archdosignalorrestart+0x34/0x100 [ 7340.429571] exittousermodeloop+0x8e/0x4c0 [ 7340.430159] dosyscall64+0x188/ ---truncated---(CVE-2026-23343)

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

netfilter: nftsetpipapo: split gc into unlink and reclaim phase

Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service).

We must split GC in an unlink and a reclaim phase.

We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure.

callrcu() does not protect us: dump operations or element lookups starting after callrcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version.

This a similar approach as done recently for the rbtree backend in commit 35f83a75529a ("netfilter: nftsetrbtree: don't gc elements on insert").(CVE-2026-23351)

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

can: bcm: fix locking for bcm_op runtime updates

Commit c2aba69d0c36 ("can: bcm: add locking for bcmop runtime updates") added a locking for some variables that can be modified at runtime when updating the sending bcmop with a new TXSETUP command in bcmtx_setup().

Usually the RXSETUP only handles and filters incoming traffic with one exception: When the RXRTRFRAME flag is set a predefined CAN frame is sent when a specific RTR frame is received. Therefore the rx bcmop uses bcmcantx() which uses the bcmtxlock that was only initialized in bcmtxsetup(). Add the missing spinlockinit() when allocating the bcmop in bcmrx_setup() to handle the RTR case properly.(CVE-2026-23362)

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

net: usb: kalmia: validate USB endpoints

The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints.(CVE-2026-23365)

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

net: phy: register phy led_triggers during probe to avoid AB-BA deadlock

There is an AB-BA deadlock when both LEDSTRIGGERNETDEV and LEDTRIGGERPHY are enabled:

[ 1362.049207] [<8054e4b8>] ledtriggerregister+0x5c/0x1fc <-- Trying to get lock "triggerslistlock" via downwrite(&triggerslistlock); [ 1362.054536] [<80662830>] phyledtriggersregister+0xd0/0x234 [ 1362.060329] [<8065e200>] phyattachdirect+0x33c/0x40c [ 1362.065489] [<80651fc4>] phylinkfwnodephyconnect+0x15c/0x23c [ 1362.071480] [<8066ee18>] mtkopen+0x7c/0xba0 [ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0 [ 1362.080384] [<806d7668>] __devchangeflags+0x244/0x24c [ 1362.085598] [<806d7698>] devchangeflags+0x28/0x78 [ 1362.090528] [<807150e4>] devioctl+0x4c0/0x654 <-- Hold lock "rtnlmutex" by calling rtnllock(); [ 1362.094985] [<80694360>] sockioctl+0x2f4/0x4e0 [ 1362.099567] [<802e9c4c>] sysioctl+0x32c/0xd8c [ 1362.104022] [<80014504>] syscallcommon+0x34/0x58

Here LEDTRIGGERPHY is registering LED triggers during phyattach while holding RTNL and then taking triggerslist_lock.

[ 1362.191101] [<806c2640>] registernetdevicenotifier+0x60/0x168 <-- Trying to get lock "rtnlmutex" via rtnllock(); [ 1362.197073] [<805504ac>] netdevtrigactivate+0x194/0x1e4 [ 1362.202490] [<8054e28c>] ledtriggerset+0x1d4/0x360 <-- Hold lock "triggerslistlock" by downread(&triggerslistlock); [ 1362.207511] [<8054eb38>] ledtriggerwrite+0xd8/0x14c [ 1362.212566] [<80381d98>] sysfskfbinwrite+0x80/0xbc [ 1362.217688] [<8037fcd8>] kernfsfopwriteiter+0x17c/0x28c [ 1362.223174] [<802cbd70>] vfswrite+0x21c/0x3c4 [ 1362.227712] [<802cc0c4>] ksyswrite+0x78/0x12c [ 1362.232164] [<80014504>] syscallcommon+0x34/0x58

Here LEDSTRIGGERNETDEV is being enabled on an LED. It first takes triggerslistlock and then RTNL. A classical AB-BA deadlock.

phyledtriggersregisters() does not require the RTNL, it does not make any calls into the network stack which require protection. There is also no requirement the PHY has been attached to a MAC, the triggers only make use of phydev state. This allows the call to phyledtriggersregisters() to be placed elsewhere. PHY probe() and release() don't hold RTNL, so solving the AB-BA deadlock.(CVE-2026-23368)

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

sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting

Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited).

sched: DL de-boosted task PID 22725: REPLENISH flag missing

WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeuetaskdl+0x15c/0x1f8 ... (runningbw underflow) Call trace: dequeuetaskdl+0x15c/0x1f8 (P) dequeuetask+0x80/0x168 deactivatetask+0x24/0x50 pushdltask+0x264/0x2e0 dltask_timer+0x1b0/0x228 _hrtimerrunqueues+0x188/0x378 hrtimerinterrupt+0xfc/0x260 ...

The problem is that when a SCHEDDEADLINE task (lock holder) is changed to a lower priority class via schedsetscheduler(), it may fail to properly inherit the parameters of potential DEADLINE donors if it didn't already inherit them in the past (shorter deadline than donor's at that time). This might lead to bandwidth accounting corruption, as enqueuetaskdl() won't recognize the lock holder as boosted.

The scenario occurs when: 1. A DEADLINE task (donor) blocks on a PI mutex held by another DEADLINE task (holder), but the holder doesn't inherit parameters (e.g., it already has a shorter deadline) 2. schedsetscheduler() changes the holder from DEADLINE to a lower class while still holding the mutex 3. The holder should now inherit DEADLINE parameters from the donor and be enqueued with ENQUEUEREPLENISH, but this doesn't happen

Fix the issue by introducing __setschedulerdlpi(), which detects when a DEADLINE (proper or boosted) task gets setscheduled to a lower priority class. In case, the function makes the task inherit DEADLINE parameters of the donoer (pise) and sets ENQUEUEREPLENISH flag to ensure proper bandwidth accounting during the next enqueue operation.(CVE-2026-23371)

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 CONFIGREADONLYTHPFOR_FS 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 kvmgmemfaultuser_mapping().

For secretmem, collapse_file() 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:memcpy_orig+0x16/0x130
Call Trace:
 collapse_file
 hpage_collapse_scan_file
 madvise_collapse

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.(CVE-2026-23375)

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

net: bridge: fix nd_tbl NULL dereference when IPv6 is disabled

When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. Then, if neighsuppress is enabled and an ICMPv6 Neighbor Discovery packet reaches the bridge, brdosuppressnd() will dereference ipv6stub->ndtbl which is NULL, passing it to neighlookup(). This causes a kernel NULL pointer dereference.

BUG: kernel NULL pointer dereference, address: 0000000000000268 Oops: 0000 [#1] PREEMPT SMP NOPTI [...] RIP: 0010:neighlookup+0x16/0xe0 [...] Call Trace: <IRQ> ? neighlookup+0x16/0xe0 brdosuppressnd+0x160/0x290 [bridge] brhandleframefinish+0x500/0x620 [bridge] brhandleframe+0x353/0x440 [bridge] __netifreceiveskb_core.constprop.0+0x298/0x1110 __netifreceiveskb_onecore+0x3d/0xa0 processbacklog+0xa0/0x140 _napipoll+0x2c/0x170 netrxaction+0x2c4/0x3a0 handlesoftirqs+0xd0/0x270 dosoftirq+0x3f/0x60

Fix this by replacing ISENABLED(IPV6) call with ipv6mod_enabled() in the callers. This is in essence disabling NS/NA suppression when IPv6 is disabled.(CVE-2026-23381)

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

netfilter: xt_CT: drop pending enqueued packets on template removal

Templates refer to objects that can go away while packets are sitting in nfqueue refer to:

• helper, this can be an issue on module removal.
• timeout policy, nfnetlink_cttimeout might remove it.

The use of templates with zone and event cache filter are safe, since this just copies values.

Flush these enqueued packets in case the template rule gets removed.(CVE-2026-23391)

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

netfilter: nf_tables: release flowtable after rcu grace period on error

Call synchronizercu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlinkhook control plane.

This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronize_rcu().

There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised.

Uncovered by KASAN reported as use-after-free from nfnetlink_hook path when dumping hooks.(CVE-2026-23392)

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

bridge: cfm: Fix race condition in peer_mep deletion

When a peer MEP is being deleted, canceldelayedworksync() is called on ccmrxdwork before freeing. However, brcfmframerx() runs in softirq context under rcureadlock (without RTNL) and can re-schedule ccmrxdwork via ccmrxtimerstart() between canceldelayedworksync() returning and kfree_rcu() being called.

The following is a simple race scenario:

       cpu0                                     cpu1

mepdeleteimplementation() canceldelayedworksync(ccmrxdwork); brcfmframerx() // peermep still in hlist if (peermep->ccmdefect) ccmrxtimerstart() queuedelayedwork(ccmrxdwork) hlistdelrcu(&peermep->head); kfreercu(peermep, rcu); ccmrxworkexpired() // on freed peer_mep

To prevent this, canceldelayedworksync() is replaced with disabledelayedworksync() in both peer MEP deletion paths, so that subsequent queuedelayedwork() calls from brcfmframe_rx() are silently rejected.

The ccpeerdisable() helper retains canceldelayedwork_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable.(CVE-2026-23393)

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

afunix: Give up GC if MSGPEEK intervened.

Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro.

This is the exact same issue previously fixed by commit cbcf01128d0a ("afunix: fix garbage collect vs MSGPEEK").

After GC was replaced with the current algorithm, the cited commit removed the locking dance in unixpeekfds() and reintroduced the same issue.

The problem is that MSG_PEEK bumps a file refcount without interacting with GC.

Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B.

The bad thing happens if sk-A is recv()ed with MSGPEEK from sk-B and sk-B is close()d while GC is checking unixvertex_dead() for sk-A and sk-B.

GC thread User thread --------- ----------- unixvertexdead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2

                           close(sk-B)
                           -> sk-B's file refcount : 2 -> 1

unixvertexdead(sk-B) -> true

Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds.

However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation.

At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former.

Finally, GC incorrectly concludes that both sk-A and sk-B are dead.

One option is to restore the locking dance in unixpeekfds(), but we can resolve this more elegantly thanks to the new algorithm.

The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection.

When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC.

Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC.

Let's use seqcountt to notify GC when MSGPEEK occurs and let it defer the SCC to the next run.

This way no locking is needed on the MSGPEEK side, and we can avoid imposing a penalty on every MSGPEEK unnecessarily.

Note that we can retry within unixsccdead() if MSGPEEK is detected, but we do not do so to avoid hung task splat from abusive MSGPEEK calls.(CVE-2026-23394)

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

Bluetooth: L2CAP: Fix accepting multiple L2CAPECREDCONN_REQ

Currently the code attempts to accept requests regardless of the command identifier which may cause multiple requests to be marked as pending (FLAGDEFERSETUP) which can cause more than L2CAPECREDMAXCID(5) to be allocated in l2capecredrspdefer causing an overflow.

The spec is quite clear that the same identifier shall not be used on subsequent requests:

'Within each signaling channel a different Identifier shall be used for each successive request or indication.' https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host/logical-link-control-and-adaptation-protocol-specification.html#UUID-32a25a06-4aa4-c6c7-77c5-dcfe3682355d

So this attempts to check if there are any channels pending with the same identifier and rejects if any are found.(CVE-2026-23395)

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

nfnetlink_osf: validate individual option lengths in fingerprints

nfnlosfaddcallback() validates optnum bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nfosfmatch_one() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL:

Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nfosfmatchone (net/netfilter/nfnetlinkosf.c:98) Call Trace: nfosfmatch (net/netfilter/nfnetlinkosf.c:227) xtosfmatchpacket (net/netfilter/xtosf.c:32) iptdotable (net/ipv4/netfilter/iptables.c:293) nfhookslow (net/netfilter/core.c:623) iplocaldeliver (net/ipv4/ipinput.c:262) iprcv (net/ipv4/ip_input.c:573)

Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nfosfmatch_one() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses "< 4" rather than "!= 4" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check.

Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.(CVE-2026-23397)

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

nftables: nftdynset: fix possible stateful expression memleak in error path

If cloning the second stateful expression in the element via GFP_ATOMIC fails, then the first stateful expression remains in place without being released.

  unreferenced object (percpu) 0x607b97e9cab8 (size 16):     comm "softirq", pid 0, jiffies 4294931867     hex dump (first 16 bytes on cpu 3):       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     backtrace (crc 0):       pcpuallocnoprof+0x453/0xd80       nftcounterclone+0x9c/0x190 [nftables]       nftexprclone+0x8f/0x1b0 [nftables]       nftdynsetnew+0x2cb/0x5f0 [nftables]       nftrhashupdate+0x236/0x11c0 [nftables]       nftdynseteval+0x11f/0x670 [nftables]       nftdochain+0x253/0x1700 [nftables]       nftdochainipv4+0x18d/0x270 [nftables]       nfhookslow+0xaa/0x1e0       iplocaldeliver+0x209/0x330(CVE-2026-23399)

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

KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE

When installing an emulated MMIO SPTE, do so after dropping/zapping the existing SPTE (if it's shadow-present). While commit a54aa15c6bda3 was right about it being impossible to convert a shadow-present SPTE to an MMIO SPTE due to a guest write, it failed to account for writes to guest memory that are outside the scope of KVM.

E.g. if host userspace modifies a shadowed gPTE to switch from a memslot to emulted MMIO and then the guest hits a relevant page fault, KVM will install the MMIO SPTE without first zapping the shadow-present SPTE.

------------[ cut here ]------------ isshadowpresentpte(*sptep) WARNING: arch/x86/kvm/mmu/mmu.c:484 at markmmiospte+0xb2/0xc0 [kvm], CPU#0: vmxeptstaler/4292 Modules linked in: kvmintel kvm irqbypass CPU: 0 UID: 1000 PID: 4292 Comm: vmxeptstaler Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:markmmiospte+0xb2/0xc0 [kvm] Call Trace: <TASK> mmusetspte+0x237/0x440 [kvm] eptpagefault+0x535/0x7f0 [kvm] kvmmmudopagefault+0xee/0x1f0 [kvm] kvmmmupagefault+0x8d/0x620 [kvm] vmxhandleexit+0x18c/0x5a0 [kvmintel] kvmarchvcpuioctlrun+0xc55/0x1c20 [kvm] kvmvcpuioctl+0x2d5/0x980 [kvm] __x64sysioctl+0x8a/0xd0 dosyscall64+0xb5/0x730 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x47fa3f </TASK> ---[ end trace 0000000000000000 ]---(CVE-2026-23401)

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

apparmor: fix memory leak in verify_header

The function sets *ns = NULL on every call, leaking the namespace string allocated in previous iterations when multiple profiles are unpacked. This also breaks namespace consistency checking since *ns is always NULL when the comparison is made.

Remove the incorrect assignment. The caller (aa_unpack) initializes *ns to NULL once before the loop, which is sufficient.(CVE-2026-23403)

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

apparmor: replace recursive profile removal with iterative approach

The profile removal code uses recursion when removing nested profiles, which can lead to kernel stack exhaustion and system crashes.

Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.remove

Replace the recursive __aaprofilelist_release() approach with an iterative approach in _removeprofile(). The function repeatedly finds and removes leaf profiles until the entire subtree is removed, maintaining the same removal semantic without recursion.(CVE-2026-23404)

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

apparmor: fix: limit the number of levels of policy namespaces

Currently the number of policy namespaces is not bounded relying on the user namespace limit. However policy namespaces aren't strictly tied to user namespaces and it is possible to create them and nest them arbitrarily deep which can be used to exhaust system resource.

Hard cap policy namespaces to the same depth as user namespaces.(CVE-2026-23405)

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

apparmor: Fix double free of nsname in aareplace_profiles()

if nsname is NULL after 1071 error = aaunpack(udata, &lh, &ns_name);

and if ent->nsname contains an nsname in 1089 } else if (ent->ns_name) {

then nsname is assigned the ent->nsname 1095 nsname = ent->nsname;

however ent->nsname is freed at 1262 aaloadentfree(ent);

and then again when freeing nsname at 1270 kfree(nsname);

Fix this by NULLing out ent->nsname after it is transferred to nsname

")(CVE-2026-23408)

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

apparmor: fix differential encoding verification

Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates.

Unfortunately the differential encode verification had two bugs.

1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified.

2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state.

Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked.(CVE-2026-23409)

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

apparmor: fix race on rawdata dereference

There is a race condition that leads to a use-after-free situation: because the rawdata inodes are not refcounted, an attacker can start open()ing one of the rawdata files, and at the same time remove the last reference to this rawdata (by removing the corresponding profile, for example), which frees its struct aaloaddata; as a result, when seqrawdataopen() is reached, iprivate is a dangling pointer and freed memory is accessed.

The rawdata inodes weren't refcounted to avoid a circular refcount and were supposed to be held by the profile rawdata reference. However during profile removal there is a window where the vfs and profile destruction race, resulting in the use after free.

Fix this by moving to a double refcount scheme. Where the profile refcount on rawdata is used to break the circular dependency. Allowing for freeing of the rawdata once all inode references to the rawdata are put.(CVE-2026-23410)

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

apparmor: fix race between freeing data and fs accessing it

AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can aand does live beyond that point and it is possible that some of the fs call back functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs.

While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private.

Fix this by moving the put of i_private referenced data to the correct place which is during inode eviction.(CVE-2026-23411)

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

clsact: Fix use-after-free in init/destroy rollback asymmetry

Fix a use-after-free in the clsact qdisc upon init/destroy rollback asymmetry. The latter is achieved by first fully initializing a clsact instance, and then in a second step having a replacement failure for the new clsact qdisc instance. clsactinit() initializes ingress first and then takes care of the egress part. This can fail midway, for example, via tcfblockgetext(). Upon failure, the kernel will trigger the clsact_destroy() callback.

Commit 1cb6f0bae504 ("bpf: Fix too early release of tcxentry") details the way how the transition is happening. If tcfblockgetext on the q->ingressblock ends up failing, we took the tcxminiqinc reference count on the ingress side, but not yet on the egress side. clsactdestroy() tests whether the {ingress,egress}entry was non-NULL. However, even in midway failure on the replacement, both are in fact non-NULL with a valid egressentry from the previous clsact instance.

What we really need to test for is whether the qdisc instance-specific ingress or egress side previously got initialized. This adds a small helper for checking the miniq initialization called miniqdiscpairinited, and utilizes that upon clsactdestroy() in order to fix the use-after-free scenario. Convert the ingress_destroy() side as well so both are consistent to each other.(CVE-2026-23413)

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

tls: Purge asynchold in tlsdecryptasyncwait()

The asynchold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tlsdecryptasyncwait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally.

A subsequent patch adds batch async decryption to tlsswread_sock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move _skbqueuepurge(&ctx->asynchold) into tlsdecryptasyncwait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tlsdodecryption(), and the new readsock batch path -- releases held skbs on synchronization without each site managing the purge independently.

This fixes a leak when tlsstrpmsghold() fails part-way through, after having added some cloned skbs to the asynchold queue. tlsdecryptsg() will then call tlsdecryptasyncwait() to process all pending decrypts, and drop back to synchronous mode, but tlsswrecvmsg() only flushes the asynchold queue when one record has been processed in "fully-async" mode, which may not be the case here.

[(CVE-2026-23414)

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

xen/privcmd: restrict usage in unprivileged domU

The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains.

In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature.

The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest.

Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today.

The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot.

This is XSA-482

V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)(CVE-2026-31788)