OESA-2026-1832

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ksmbd: fix use-after-free in ksmbdtreeconnect_put under concurrency

Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it.(CVE-2025-68817)

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

tpm: Cap the number of PCR banks

tpm2getpcr_allocation() does not cap any upper limit for the number of banks. Cap the limit to eight banks so that out of bounds values coming from external I/O cause on only limited harm.(CVE-2025-71077)

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

mm/page_alloc: change all pageblocks migrate type on coalescing

When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed.

However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged.

That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced.

[ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/pagealloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algifhash(E) afalg(E) nftfibinet(E) nftfibipv4(E) nftfibipv6(E) nftfib(E) nftrejectinet(E) nfrejectipv4(E) nfrejectipv6(E) nftreject(E) nftct(E) nftchainnat(E) nfnat(E) nfconntrack(E) nfdefragipv6(E) nfdefragipv4(E) nftables(E) s390trng(E) vfioccw(E) mdev(E) vfioiommutype1(E) vfio(E) schfqcodel(E) drm(E) i2ccore(E) drmpanelorientationquirks(E) loop(E) nfnetlink(E) vsockloopback(E) vmwvsockvirtiotransportcommon(E) vsock(E) ctcm(E) fsm(E) diag288wdt(E) watchdog(E) zfcp(E) scsitransportfc(E) ghashs390(E) prng(E) aess390(E) desgeneric(E) dess390(E) libdes(E) sha3512s390(E) sha3256s390(E) shacommon(E) paess390(E) cryptoengine(E) pkeycca(E) pkeyep11(E) zcrypt(E) rngcore(E) pkeypckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmacs390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempigverify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNEDMODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60 #00000349976fa5fc: af000000 mc 0,0 >00000349976fa600: a7f4ff4c brc 15,00000349976fa498 00000349976fa604: b9040026 lgr %r2,%r6 00000349976fa608: c0300088317f larl %r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0 00000349976fa614: af000000 mc 0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueuebulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueuepcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] getpagefromfreelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __allocfrozenpagesnoprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] allocpagesmpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folioallocmpolnoprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vmaallocfolionoprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vmaallocanonfolio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __dohugepmdanonymouspage+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---(CVE-2025-71134)

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

net: dsa: properly keep track of conduit reference

Problem description

DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.

There are two distinct problems.

1. The OF path, which uses offindnetdevicebynode(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsadevtonetdevice() has a putdevice() call which is missing in dsaportparseof(), but we can actually even verify that an issue exists. With CONFIGDEBUGKOBJECTRELEASE=y, if we run this command "before" and "after" applying this patch:

(unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind

we see these lines in the output diff which appear only with the patch applied:

kobject: 'eno2' (ffff002009a3a6b8): kobjectrelease, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobjectrelease, parent 0000000000000000 (delayed 1000)

2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpudp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (devhold() and dev_put()).

Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdevupperdevlink(). But time still passes at DSA switch probe time between the initial offindnetdevicebynode() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.

So we have to run offindnetdevicebynode() under rtnllock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.

Do we need to keep the reference until dsaunregisterswitch() / dsaswitchshutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpudp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsatreefindfirst_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed.

As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.

History and blame attribution

The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.

We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---(CVE-2025-71152)

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

net: usb: rtl8150: fix memory leak on usbsubmiturb() failure

In asyncsetregisters(), when usbsubmiturb() fails, the allocated async_req structure and URB are not freed, causing a memory leak.

The completion callback asyncsetreg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.

Fix this by freeing both the URB and the request structure in the error path when usbsubmiturb() fails.(CVE-2025-71154)

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

scsi: qla2xxx: Fix bsg_done() causing double free

Kernel panic observed on system,

[5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: errorcode(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el95.x8664 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpyerms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] <TASK> [5353358.825224] ? showtraceloglvl+0x1c4/0x2df [5353358.825229] ? showtraceloglvl+0x1c4/0x2df [5353358.825232] ? sgcopybuffer+0xc8/0x110 [5353358.825236] ? _diebody.cold+0x8/0xd [5353358.825238] ? pagefaultoops+0x134/0x170 [5353358.825242] ? kernelmodefixuporoops+0x84/0x110 [5353358.825244] ? excpagefault+0xa8/0x150 [5353358.825247] ? asmexcpagefault+0x22/0x30 [5353358.825252] ? memcpyerms+0x6/0x10 [5353358.825253] sgcopybuffer+0xc8/0x110 [5353358.825259] qla2x00processvendorspecific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xxbsgrequest+0x1b2/0x2d0 [qla2xxx]

Most routines in qlabsg.c call bsgdone() only for success cases. However a few invoke it for failure case as well leading to a double free. Validate before calling bsg_done().(CVE-2025-71238)

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

wifi: avoid kernel-infoleak from struct iw_point

struct iw_point has a 32bit hole on 64bit arches.

struct iw_point { void __user pointer; / Pointer to the data (in user space) / __u16 length; / number of fields or size in bytes / __u16 flags; / Optional params */ };

Make sure to zero the structure to avoid disclosing 32bits of kernel data to user space.(CVE-2026-22978)

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4end_grace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4end_grace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceend_forced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.(CVE-2026-22980)

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

libceph: replace overzealous BUGON in osdmapapply_incremental()

If the osdmap is (maliciously) corrupted such that the incremental osdmap epoch is different from what is expected, there is no need to BUG. Instead, just declare the incremental osdmap to be invalid.(CVE-2026-22990)

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

libceph: return the handler error from monhandleauth_done()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauth_signature().(CVE-2026-22992)

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

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).

Add a minimum AAD length check to fail fast on invalid inputs.(CVE-2026-23060)

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

vsock/virtio: fix potential underflow in virtiotransportget_credit()

The credit calculation in virtiotransportget_credit() uses unsigned arithmetic:

ret = vvs->peerbufalloc - (vvs->txcnt - vvs->peerfwd_cnt);

If the peer shrinks its advertised buffer (peerbufalloc) while bytes are in flight, the subtraction can underflow and produce a large positive value, potentially allowing more data to be queued than the peer can handle.

Reuse virtiotransporthas_space() which already handles this case and add a comment to make it clear why we are doing that.

[Stefano: use virtiotransporthas_space() instead of duplicating the code] Stefano: tweak the commit message

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

regmap: Fix race condition in hwspinlock irqsave routine

Previously, the address of the shared member '&map->spinlockflags' was passed directly to 'hwspinlocktimeoutirqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shared flags variable, potentially corrupting the state for the current lock owner.

Fix this by using a local stack variable 'flags' to store the IRQ state temporarily.(CVE-2026-23071)

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

vsock/virtio: cap TX credit to local buffer size

The virtio transports derives its TX credit directly from peerbufalloc, which is set from the remote endpoint's SOVMSOCKETSBUFFERSIZE value.

On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of sk_buff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base.

Introduce a small helper, virtiotransporttxbufsize(), that returns min(peerbufalloc, bufalloc), and use it wherever we consume peerbuf_alloc.

This ensures the effective TX window is bounded by both the peer's advertised buffer and our own bufalloc (already clamped to buffermaxsize via SOVMSOCKETSBUFFERMAXSIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings.

On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited.

With this patch applied:

Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB

After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB

Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive.

Compatibility with non-virtio transports:

• VMCI uses the AFVSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer* values; the remote side cannot enlarge those queues beyond what the local endpoint configured.

• Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peerbufalloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes.

• The loopback path reuses virtiotransportcommon.c, so it naturally follows the same semantics as the virtio transport.

This change is limited to virtiotransportcommon.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have.

[Stefano: small adjustments after changing the previous patch] Stefano: tweak the commit message

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

bonding: limit BONDMODE8023AD to Ethernet devices

BONDMODE8023AD makes sense for ARPHRD_ETHER only.

syzbot reported:

BUG: KASAN: global-out-of-bounds in __hwaddrcreate net/core/devaddrlists.c:63 [inline] BUG: KASAN: global-out-of-bounds in _hwaddraddex+0x25d/0x760 net/core/devaddrlists.c:118 Read of size 16 at addr ffffffff8bf94040 by task syz.1.3580/19497

CPU: 1 UID: 0 PID: 19497 Comm: syz.1.3580 Tainted: G L syzkaller #0 PREEMPT(full) Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstacklvl+0xe8/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xca/0x240 mm/kasan/report.c:482 kasanreport+0x118/0x150 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:-1 [inline] kasancheck_range+0x2b0/0x2c0 mm/kasan/generic.c:200 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 __hwaddrcreate net/core/devaddrlists.c:63 [inline] __hwaddraddex+0x25d/0x760 net/core/devaddr_lists.c:118 __devmcadd net/core/devaddrlists.c:868 [inline] devmcadd+0xa1/0x120 net/core/devaddrlists.c:886 bondenslave+0x2b8b/0x3ac0 drivers/net/bonding/bondmain.c:2180 dosetmaster+0x533/0x6d0 net/core/rtnetlink.c:2963 dosetlink+0xcf0/0x41c0 net/core/rtnetlink.c:3165 rtnlchangelink net/core/rtnetlink.c:3776 [inline] __rtnlnewlink net/core/rtnetlink.c:3935 [inline] rtnlnewlink+0x161c/0x1c90 net/core/rtnetlink.c:4072 rtnetlinkrcvmsg+0x7cf/0xb70 net/core/rtnetlink.c:6958 netlinkrcvskb+0x208/0x470 net/netlink/afnetlink.c:2550 netlinkunicastkernel net/netlink/afnetlink.c:1318 [inline] netlinkunicast+0x82f/0x9e0 net/netlink/afnetlink.c:1344 netlinksendmsg+0x805/0xb30 net/netlink/afnetlink.c:1894 socksendmsgnosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 ____sys_sendmsg+0x505/0x820 net/socket.c:2592 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2646 __syssendmsg+0x164/0x220 net/socket.c:2678 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] __dofastsyscall32+0x1dc/0x560 arch/x86/entry/syscall32.c:307 dofastsyscall32+0x34/0x80 arch/x86/entry/syscall32.c:332 entrySYSENTERcompatafterhwframe+0x84/0x8e </TASK>

The buggy address belongs to the variable: lacpdumcastaddr+0x0/0x40(CVE-2026-23099)

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

ipvlan: Make the addrs_lock be per port

Make the addrs_lock be per port, not per ipvlan dev.

Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So

1) Introduce per-port addrs_lock.

2) It was needed to fix places where it was forgotten to take lock (ipvlanopen/ipvlanclose)

This appears to be a very minor problem though. Since it's highly unlikely that ipvlanaddaddr() will be called on 2 CPU simultaneously. But nevertheless, this could cause:

1) False-negative of ipvlanaddrbusy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlanaddr6event() can be called without rtnl_lock.

2) Race since ipvlanhtaddradd(port) is called under different ipvlan->addrslock locks

This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.(CVE-2026-23103)

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

net/sched: qfq: Use clisactive to determine whether class is active in qfqrmfrom_ag

This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. use clisactive instead of relying on the child qdisc's qlen to determine class activation.(CVE-2026-23105)

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

netfilter: nftables: fix inverted genmask check in nftmapcatchallactivate()

nftmapcatchallactivate() has an inverted element activity check compared to its non-catchall counterpart nftmapelem_activate() and compared to what is logically required.

nftmapcatchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.

Compare the non-catchall activate callback, which is correct:

nftmapelemactivate(): if (nftsetelem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */

With the buggy catchall version:

nftmapcatchallactivate(): if (!nftsetelemactive(ext, genmask)) continue; /* skip inactive, process active */

The consequence is that when a DELSET operation is aborted, nftsetelemdataactivate() is never called for the catchall element. For NFTGOTO verdict elements, this means nftdatahold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.

This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIGUSERNS and CONFIGNFTABLES.

Fix by removing the negation so the check matches nftmapelemactivate(): skip active elements, process inactive ones.(CVE-2026-23111)

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

l2tp: avoid one data-race in l2tptunneldel_work()

We should read sk->sk_socket only when dealing with kernel sockets.

syzbot reported the following data-race:

BUG: KCSAN: data-race in l2tptunneldelwork / skcommon_release

write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0: sksetsocket include/net/sock.h:2092 [inline] sockorphan include/net/sock.h:2118 [inline] skcommonrelease+0xae/0x230 net/core/sock.c:4003 udplibclose+0x15/0x20 include/net/udp.h:325 inetrelease+0xce/0xf0 net/ipv4/af_inet.c:437 __sockrelease net/socket.c:662 [inline] sockclose+0x6b/0x150 net/socket.c:1455 __fput+0x29b/0x650 fs/file_table.c:468 ____fput+0x1c/0x30 fs/filetable.c:496 taskworkrun+0x131/0x1a0 kernel/taskwork.c:233 resumeusermode_work include/linux/resumeusermode.h:50 [inline] __exittousermodeloop kernel/entry/common.c:44 [inline] exittousermodeloop+0x1fe/0x740 kernel/entry/common.c:75 _exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x1e1/0x2b0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1: l2tptunneldelwork+0x2f/0x1a0 net/l2tp/l2tpcore.c:1418 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0x4ce/0x9d0 kernel/workqueue.c:3340 workerthread+0x582/0x770 kernel/workqueue.c:3421 kthread+0x489/0x510 kernel/kthread.c:463 retfromfork+0x149/0x290 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:246

value changed: 0xffff88811b818000 -> 0x0000000000000000(CVE-2026-23120)

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

ipv6: annotate data-race in ndiscrouterdiscovery()

syzbot found that ndiscrouterdiscovery() could read and write in6dev->ramtu without holding a lock [1]

This looks fine, IFLAINET6RA_MTU is best effort.

Add READONCE()/WRITEONCE() to document the race.

Note that we might also reject illegal MTU values (mtu < IPV6MINMTU || mtu > skb->dev->mtu) in a future patch.

[1] BUG: KCSAN: data-race in ndiscrouterdiscovery / ndiscrouterdiscovery

read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1: ndiscrouterdiscovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558 ndiscrcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6protocoldeliverrcu+0xb2a/0x10d0 net/ipv6/ip6input.c:438 ip6inputfinish+0xf0/0x1d0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x5e/0x140 net/ipv6/ip6input.c:500 ip6mcinput+0x27c/0x470 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x336/0x340 net/ipv6/ip6_input.c:79 ...

write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0: ndiscrouterdiscovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559 ndiscrcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841 icmpv6rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989 ip6protocoldeliverrcu+0xb2a/0x10d0 net/ipv6/ip6input.c:438 ip6inputfinish+0xf0/0x1d0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x5e/0x140 net/ipv6/ip6input.c:500 ip6mcinput+0x27c/0x470 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x336/0x340 net/ipv6/ip6_input.c:79 ...

value changed: 0x00000000 -> 0xe5400659(CVE-2026-23124)

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

netdevsim: fix a race issue related to the operation on bpfboundprogs list

The netdevsim driver lacks a protection mechanism for operations on the bpfboundprogs list. When the nsimbpfcreateprog() performs listaddtail, it is possible that nsimbpfdestroyprog() is simultaneously performs list_del. Concurrent operations on the list may lead to list corruption and trigger a kernel crash as follows:

[ 417.290971] kernel BUG at lib/listdebug.c:62! [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 417.291007] Workqueue: events bpfprogfreedeferred [ 417.291021] RIP: 0010:__listdelentryvalidorreport+0xa7/0xc0 [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246 [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000 [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180 [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003 [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20 [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000 [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0 [ 417.291088] PKRU: 55555554 [ 417.291091] Call Trace: [ 417.291096] <TASK> [ 417.291103] nsimbpfdestroyprog+0x31/0x80 [netdevsim] [ 417.291154] __bpfprogoffloaddestroy+0x2a/0x80 [ 417.291163] bpfprogdevbounddestroy+0x6f/0xb0 [ 417.291171] bpfprogfreedeferred+0x18e/0x1a0 [ 417.291178] processonework+0x18a/0x3a0 [ 417.291188] worker_thread+0x27b/0x3a0 [ 417.291197] ? __pfxworkerthread+0x10/0x10 [ 417.291207] kthread+0xe5/0x120 [ 417.291214] ? __pfxkthread+0x10/0x10 [ 417.291221] retfrom_fork+0x31/0x50 [ 417.291230] ? __pfxkthread+0x10/0x10 [ 417.291236] retfromforkasm+0x1a/0x30 [ 417.291246] </TASK>

Add a mutex lock, to prevent simultaneous addition and deletion operations on the list.(CVE-2026-23126)

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

wifi: ath10k: fix dmafreecoherent() pointer

dmaalloccoherent() allocates a DMA mapped buffer and stores the addresses in XXX_unaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.(CVE-2026-23133)

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

libceph: reset sparse-read state in osd_fault()

When a fault occurs, the connection is abandoned, reestablished, and any pending operations are retried. The OSD client tracks the progress of a sparse-read reply using a separate state machine, largely independent of the messenger's state.

If a connection is lost mid-payload or the sparse-read state machine returns an error, the sparse-read state is not reset. The OSD client will then interpret the beginning of a new reply as the continuation of the old one. If this makes the sparse-read machinery enter a failure state, it may never recover, producing loops like:

libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read

Therefore, reset the sparse-read state in osd_fault(), ensuring retries start from a clean state.(CVE-2026-23136)

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

of: unittest: Fix memory leak in unittestdataadd()

In unittestdataadd(), if ofresolvephandles() fails, the allocated unittest_data is not freed, leading to a memory leak.

Fix this by using scope-based cleanup helper _free(kfree) for automatic resource cleanup. This ensures unittestdata is automatically freed when it goes out of scope in error paths.

For the success path, use retainandnull_ptr() to transfer ownership of the memory to the device tree and prevent double freeing.(CVE-2026-23137)

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

netfilter: nfconncount: update lastgc only when GC has been performed

Currently last_gc is being updated everytime a new connection is tracked, that means that it is updated even if a GC wasn't performed. With a sufficiently high packet rate, it is possible to always bypass the GC, causing the list to grow infinitely.

Update the last_gc value only when a GC has been actually performed.(CVE-2026-23139)

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

ext4: fix iloc.bh leak in ext4xattrinodeupdateref

The error branch for ext4xattrinodeupdateref forget to release the refcount for iloc.bh. Find this when review code.(CVE-2026-23145)

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

net: fix segmentation of forwarding fraglist GRO

This patch enhances GSO segment handling by properly checking the SKBGSODODGY flag for frag_list GSO packets, addressing low throughput issues observed when a station accesses IPv4 servers via hotspots with an IPv6-only upstream interface.

Specifically, it fixes a bug in GSO segmentation when forwarding GRO packets containing a fraglist. The function skbsegmentlist cannot correctly process GRO skbs that have been converted by XLAT, since XLAT only translates the header of the head skb. Consequently, skbs in the fraglist may remain untranslated, resulting in protocol inconsistencies and reduced throughput.

To address this, the patch explicitly sets the SKBGSODODGY flag for GSO packets in XLAT's IPv4/IPv6 protocol translation helpers (bpfskbproto4to6 and bpfskbproto6to4). This marks GSO packets as potentially modified after protocol translation. As a result, GSO segmentation will avoid using skbsegmentlist and instead falls back to skbsegment for packets with the SKBGSODODGY flag. This ensures that only safe and fully translated fraglist packets are processed by skbsegmentlist, resolving protocol inconsistencies and improving throughput when forwarding GRO packets converted by XLAT.(CVE-2026-23154)

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

efivarfs: fix error propagation in efivarentryget()

efivarentryget() always returns success even if the underlying __efivarentryget() fails, masking errors.

This may result in uninitialized heap memory being copied to userspace in the efivarfsfileread() path.

Fix it by returning the error from __efivarentryget().(CVE-2026-23156)

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

mptcp: fix race in mptcppmnlflushaddrs_doit()

syzbot and Eulgyu Kim reported crashes in mptcppmnlgetlocalid() and/or mptcppmnlis_backup()

Root cause is listspliceinit() in mptcppmnlflushaddrs_doit() which is not RCU ready.

listspliceinit_rcu() can not be called here while holding pernet->lock spinlock.

Many thanks to Eulgyu Kim for providing a repro and testing our patches.(CVE-2026-23169)

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

net/mlx5e: TC, delete flows only for existing peers

When deleting TC steering flows, iterate only over actual devcom peers instead of assuming all possible ports exist. This avoids touching non-existent peers and ensures cleanup is limited to devices the driver is currently connected to.

BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 133c8a067 P4D 0 Oops: Oops: 0002 [#1] SMP CPU: 19 UID: 0 PID: 2169 Comm: tc Not tainted 6.18.0+ #156 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5etcdelfdbpeersflow+0xbe/0x200 [mlx5core] Code: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff <48> 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49 RSP: 0018:ff11000143867528 EFLAGS: 00010246 RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000 RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0 RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002 R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78 R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0 FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0 Call Trace: <TASK> mlx5etcdelflow+0x46/0x270 [mlx5core] mlx5eflowput+0x25/0x50 [mlx5core] mlx5edeleteflower+0x2a6/0x3e0 [mlx5core] tcsetupcbreoffload+0x20/0x80 flreoffload+0x26f/0x2f0 [clsflower] ? mlx5etcreoffloadflowswork+0xc0/0xc0 [mlx5core] ? mlx5etcreoffloadflowswork+0xc0/0xc0 [mlx5core] tcfblockplaybackoffloads+0x9e/0x1c0 tcfblockunbind+0x7b/0xd0 tcfblocksetup+0x186/0x1d0 tcfblockoffloadcmd.isra.0+0xef/0x130 tcfblockoffload_unbind+0x43/0x70 __tcfblockput+0x85/0x160 ingressdestroy+0x32/0x110 [schingress] __qdiscdestroy+0x44/0x100 qdiscgraft+0x22b/0x610 tcgetqdisc+0x183/0x4d0 rtnetlinkrcvmsg+0x2d7/0x3d0 ? rtnlcalcit.isra.0+0x100/0x100 netlinkrcvskb+0x53/0x100 netlinkunicast+0x249/0x320 ? __allocskb+0x102/0x1f0 netlinksendmsg+0x1e3/0x420 __sock_sendmsg+0x38/0x60 ____syssendmsg+0x1ef/0x230 ? copymsghdrfromuser+0x6c/0xa0 ___sys_sendmsg+0x7f/0xc0 ? ___sys_recvmsg+0x8a/0xc0 ? __sys_sendto+0x119/0x180 __syssendmsg+0x61/0xb0 dosyscall64+0x55/0x640 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f35238bb764 Code: 15 b9 86 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bf 0f 1f 44 00 00 f3 0f 1e fa 80 3d e5 08 0d 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 4c c3 0f 1f 00 55 48 89 e5 48 83 ec 20 89 55 RSP: 002b:00007ffed4c35638 EFLAGS: 00000202 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a2efcc75e0 RCX: 00007f35238bb764 RDX: 0000000000000000 RSI: 00007ffed4c356a0 RDI: 0000000000000003 RBP: 00007ffed4c35710 R08: 0000000000000010 R09: 00007f3523984b20 R10: 0000000000000004 R11: 0000000000000202 R12: 00007ffed4c35790 R13: 000000006947df8f R14: 000055a2efcc75e0 R15: 00007ffed4c35780(CVE-2026-23173)

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

ALSA: aloop: Fix racy access at PCM trigger

The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.

For addressing the UAF, this patch changes two things: - It covers the most of code in loopbackcheckformat() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.(CVE-2026-23191)

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

KVM: Don't clobber irqfd routing type when deassigning irqfd

When deassigning a KVMIRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvmarchirqbypassdelproducer() on x86 and arm64, which explicitly look for KVMIRQROUTINGMSI. Instead, to handle a concurrent routing update, verify that the irqfd is still active before consuming the routing information. As evidenced by the x86 and arm64 bugs, and another bug in kvmarchupdateirqfd_routing() (see below), clobbering the entry type without notifying arch code is surprising and error prone.

As a bonus, checking that the irqfd is active provides a convenient location for documenting why KVM must not consume the routing entry for an irqfd that is in the process of being deassigned: once the irqfd is deleted from the list (which happens before the eventfd is detached), it will no longer receive updates via kvmirqroutingupdate(), and so KVM could deliver an event using stale routing information (relative to KVMSETGSIROUTING returning to userspace).

As an even better bonus, explicitly checking for the irqfd being active fixes a similar bug to the one the clobbering is trying to prevent: if an irqfd is deactivated, and then its routing is changed, kvmirqroutingupdate() won't invoke kvmarchupdateirqfd_routing() (because the irqfd isn't in the list). And so if the irqfd is in bypass mode, IRQs will continue to be posted using the old routing information.

As for kvmarchirqbypassdel_producer(), clobbering the routing type results in KVM incorrectly keeping the IRQ in bypass mode, which is especially problematic on AMD as KVM tracks IRQs that are being posted to a vCPU in a list whose lifetime is tied to the irqfd.

Without the help of KASAN to detect use-after-free, the most common sympton on AMD is a NULL pointer deref in amdiommuupdatega() due to the memory for irqfd structure being re-allocated and zeroed, resulting in irqfd->irqbypassdata being NULL when read by avicupdateiommuvcpu_affinity():

BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfioirqtest Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amdiommuupdatega+0x19/0xe0 Call Trace: <TASK> avicupdateiommuvcpuaffinity+0x3d/0x90 [kvmamd] __avicvcpuload+0xf4/0x130 [kvm_amd] kvmarchvcpuload+0x89/0x210 [kvm] vcpuload+0x30/0x40 [kvm] kvmarchvcpuioctlrun+0x45/0x620 [kvm] kvmvcpuioctl+0x571/0x6a0 [kvm] __sesysioctl+0x6d/0xb0 dosyscall64+0x6f/0x9d0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x46893b </TASK> ---[ end trace 0000000000000000 ]---

If AVIC is inhibited when the irfd is deassigned, the bug will manifest as list corruption, e.g. on the next irqfd assignment.

listadd corruption. next->prev should be prev (ffff8d474d5cd588), but was 0000000000000000. (next=ffff8d8658f86530). ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:31! Oops: invalid opcode: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfioirqtest Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:listaddvalidorreport+0x97/0xc0 Call Trace: <TASK> avicpiupdateirte+0x28e/0x2b0 [kvmamd] kvmpiupdateirte+0xbf/0x190 [kvm] kvmarchirqbypassaddproducer+0x72/0x90 [kvm] irqbypassregisterconsumer+0xcd/0x170 [irqbypa ---truncated---(CVE-2026-23198)

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointer_careful() instead.

GangMin Kim provided a report and a repro fooling u32_classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221(CVE-2026-23204)

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

ALSA: usb-audio: Prevent excessive number of frames

In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].

Added a check for the number of single data URB frames when calculating the number of frames to prevent [1].

[1] BUG: KASAN: slab-out-of-bounds in copytourb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copytourb+0x261/0x460 sound/usb/pcm.c:1487 prepareplaybackurb+0x953/0x13d0 sound/usb/pcm.c:1611 prepareoutboundurb+0x377/0xc50 sound/usb/endpoint.c:333(CVE-2026-23208)

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

bonding: annotate data-races around slave->last_rx

slave->lastrx and slave->targetlastarprx[...] can be read and written locklessly. Add READONCE() and WRITEONCE() annotations.

syzbot reported:

BUG: KCSAN: data-race in bondrcvvalidate / bondrcvvalidate

write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1: bondrcvvalidate+0x202/0x7a0 drivers/net/bonding/bondmain.c:3335 bondhandleframe+0xde/0x5e0 drivers/net/bonding/bondmain.c:1533 __netifreceiveskb_core+0x5b1/0x1950 net/core/dev.c:6039 __netifreceiveskbonecore net/core/dev.c:6150 [inline] _netifreceiveskb+0x59/0x270 net/core/dev.c:6265 netifreceiveskbinternal net/core/dev.c:6351 [inline] netifreceiveskb+0x4b/0x2d0 net/core/dev.c:6410 ...

write to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0: bondrcvvalidate+0x202/0x7a0 drivers/net/bonding/bondmain.c:3335 bondhandleframe+0xde/0x5e0 drivers/net/bonding/bondmain.c:1533 __netifreceiveskb_core+0x5b1/0x1950 net/core/dev.c:6039 __netifreceiveskbonecore net/core/dev.c:6150 [inline] __netifreceiveskb+0x59/0x270 net/core/dev.c:6265 netifreceiveskbinternal net/core/dev.c:6351 [inline] netifreceiveskb+0x4b/0x2d0 net/core/dev.c:6410 brnetifreceiveskb net/bridge/brinput.c:30 [inline] NFHOOK include/linux/netfilter.h:318 [inline] ...

value changed: 0x0000000100005365 -> 0x0000000100005366(CVE-2026-23212)

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

bus: fsl-mc: fix use-after-free in driveroverrideshow()

The driveroverrideshow() function reads the driveroverride string without holding the devicelock. However, driveroverridestore() uses driversetoverride(), which modifies and frees the string while holding the device_lock.

This can result in a concurrent use-after-free if the string is freed by the store function while being read by the show function.

Fix this by holding the device_lock around the read operation.(CVE-2026-23221)

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

smb: client: split cached_fid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x86_64), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.(CVE-2026-23230)