OESA-2026-2077

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bonding: fix use-after-free due to enslave fail after slave array update

Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems.

It is very easy to reproduce the problem with a simple xdppass prog: ip l add bond1 type bond mode balance-xor ip l set bond1 up ip l set dev bond1 xdp object xdppass.o sec xdp_pass ip l add dumdum type dummy

Then run in parallel: while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done; mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"

The crash happens almost immediately: [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf] [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary) [ 605.602979] Tainted: [B]=BADPAGE [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 605.603032] RIP: 0010:netdevcorepicktx+0xcd/0x210 [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89 [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213 [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000 [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000 [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84 [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000 [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0 [ 605.603373] Call Trace: [ 605.603392] <TASK> [ 605.603410] __devqueuexmit+0x448/0x32a0 [ 605.603434] ? __pfxvprintkemit+0x10/0x10 [ 605.603461] ? __pfxvprintkpfxvprintkemit+0x10/0x10 [ 605.603484] ? pfxevqueuexmit+0x10/0x10 [ 605.603507] ? bondstartxmit+0xbfb/0xc20 [bonding] [ 605.603546] ? printk+0xcb/0x100 [ 605.603566] ? pfxprintk+0x10/0x10 [ 605.603589] ? bondstartxmit+0xbfb/0xc20 [bonding] [ 605.603627] ? addtaint+0x5e/0x70 [ 605.603648] ? addtaint+0x2a/0x70 [ 605.603670] ? endreport.cold+0x51/0x75 [ 605.603693] ? bondstartxmit+0xbfb/0xc20 [bonding] [ 605.603731] bondstartxmit+0x623/0xc20 bonding

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

udptunnel: fix NULL deref caused by udpsockcreate6 when CONFIGIPV6=n

When CONFIGIPV6 is disabled, the udpsockcreate6() function returns 0 (success) without actually creating a socket. Callers such as foucreate() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.

The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:founladddoit (net/ipv4/foucore.c:590 net/ipv4/foucore.c:764) [...] Call Trace: <TASK> genlfamilyrcvmsgdoit.constprop.0 (net/netlink/genetlink.c:1114) genlrcvmsg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlinkrcvskb (net/netlink/afnetlink.c:2550) genlrcv (net/netlink/genetlink.c:1219) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) __sock_sendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) __sys_sendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) _x64syssendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (net/arch/x86/entry/entry64.S:130)

This patch makes udpsockcreate6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.(CVE-2026-23439)

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

net/smc: fix NULL dereference and UAF in smctcpsynrecvsock()

Syzkaller reported a panic in smctcpsynrecvsock() [1].

smctcpsynrecvsock() is called in the TCP receive path (softirq) via icskafops->synrecvsock on the clcsock (TCP listening socket). It reads skuserdata to get the smcsock pointer. However, when the SMC listen socket is being closed concurrently, smccloseactive() sets clcsock->skuserdata to NULL under skcallbacklock, and then the smcsock itself can be freed via sockput() in smcrelease().

This leads to two issues:

1) NULL pointer dereference: skuserdata is NULL when accessed. 2) Use-after-free: skuserdata is read as non-NULL, but the smcsock is freed before its fields (e.g., queuedsmchs, oriaf_ops) are accessed.

The race window looks like this (the syzkaller crash [1] triggers via the SYN cookie path: tcpgetcookiesock() -> smctcpsynrecvsock(), but the normal tcpcheck_req() path has the same race):

CPU A (softirq) CPU B (process ctx)

tcpv4rcv() TCPNEWSYNRECV: sk = req->rsklistener sockhold(sk) /* No lock on listener */ smccloseactive(): writelockbh(cblock) skuserdata = NULL writeunlockbh(cblock) ... smcclcsockrelease() sockput(smc->sk) x2 -> smcsock freed! tcpcheckreq() smctcpsynrecvsock(): smc = userdata(sk) -> NULL or dangling smc->queuedsmchs -> crash!

Note that the clcsock and smcsock are two independent objects with separate refcounts. TCP stack holds a reference on the clcsock, which keeps it alive, but this does NOT prevent the smcsock from being freed.

Fix this by using RCU and refcountincnotzero() to safely access smcsock. Since smctcpsynrecvsock() is called in the TCP three-way handshake path, taking readlockbh on skcallbacklock is too heavy and would not survive a SYN flood attack. Using rcureadlock() is much more lightweight.

• Set SOCKRCUFREE on the SMC listen socket so that smcsock freeing is deferred until after the RCU grace period. This guarantees the memory is still valid when accessed inside rcuread_lock().
• Use rcureadlock() to protect reading skuserdata.
• Use refcountincnotzero(&smc->sk.skrefcnt) to pin the smc_sock. If the refcount has already reached zero (close path completed), it returns false and we bail out safely.

Note: smchscongested() has a similar lockless read of skuserdata without rcureadlock(), but it only checks for NULL and accesses the global smchswq, never dereferencing any smc_sock field, so it is not affected.

Reproducer was verified with mdelay injection and smc_run, the issue no longer occurs with this patch applied.

[1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9(CVE-2026-23450)

In the Linux kernel, a memory leak vulnerability has been identified in the sunrpc subsystem. When a reader's file descriptor is closed while in the middle of reading a cacherequest (rp->offset != 0), cacherelease() decrements the request's readers count but never checks whether it should free the request.

In cacheread(), when readers drops to 0 and CACHEPENDING is clear, the cacherequest is removed from the queue and freed along with its buffer and cachehead reference. cache_release() lacks this cleanup.

The only other path that frees requests with readers == 0 is cachedequeue(), but it runs only when CACHEPENDING transitions from set to clear. If that transition already happened while readers was still non-zero, cache_dequeue() will have skipped the request, and no subsequent call will clean it up.

The solution is to add the same cleanup logic from cacheread() to cacherelease(): after decrementing readers, check if it reached 0 with CACHEPENDING clear, and if so, dequeue and free the cacherequest.(CVE-2026-31400)

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

nfsd: fix heap overflow in NFSv4.0 LOCK replay cache

The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rpibuf[NFSD4REPLAYISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4OPAQUE_LIMIT).

When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4encodeoperation() copies the full encoded response into the undersized replay buffer via readbytesfromxdrbuf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory.

This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial.

We could fix this by increasing NFSD4REPLAYISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large.

Instead, fix this by checking the encoded response length against NFSD4REPLAYISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.(CVE-2026-31402)

In the Linux kernel, the following vulnerability has been resolved: NFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd. The /proc/fs/nfs/exports proc entry is created at module init and persists for the module's lifetime. exportsprocopen() captures the caller's current network namespace and stores its svcexportcache in seq->private, but takes no reference on the namespace. If the namespace is subsequently torn down (e.g. container destruction after the opener does setns() to a different namespace), nfsdnetexit() calls nfsdexportshutdown() which frees the cache. Subsequent reads on the still-open fd dereference the freed cachedetail, walking a freed hash table. Hold a reference on the struct net for the lifetime of the open file descriptor. This prevents nfsdnetexit() from running -- and thus prevents nfsdexportshutdown() from freeing the cache -- while any exports fd is open. cachedetail already stores its net pointer (cd->net, set by cachecreatenet()), so exports_release() can retrieve it without additional per-file storage.(CVE-2026-31403)

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

ACPI: EC: clean up handlers on probe failure in acpiecsetup()

When ecinstallhandlers() returns -EPROBEDEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpiec pointer as handler context. However, acpiecsetup() propagates the error without any cleanup.

The caller acpiecadd() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA.

Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpiecspace_handler() with the freed pointer, causing a use-after-free:

BUG: KASAN: slab-use-after-free in mutexlock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: <TASK> mutexlock (kernel/locking/mutex.c:289) acpiecspacehandler (drivers/acpi/ec.c:1362) acpievaddressspacedispatch (drivers/acpi/acpica/evregion.c:293) acpiexaccessregion (drivers/acpi/acpica/exfldio.c:246) acpiexfielddatumio (drivers/acpi/acpica/exfldio.c:509) acpiexextractfromfield (drivers/acpi/acpica/exfldio.c:700) acpiexreaddatafromfield (drivers/acpi/acpica/exfield.c:327) acpiexresolvenodetovalue (drivers/acpi/acpica/exresolv.c:392) </TASK>

Allocated by task 1: acpiecalloc (drivers/acpi/ec.c:1424) acpiecadd (drivers/acpi/ec.c:1692)

Freed by task 1: kfree (mm/slub.c:6876) acpiecadd (drivers/acpi/ec.c:1751)

The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer.

Fix this by calling ecremovehandlers() in the error path of acpiecsetup() before clearing firstec. ecremovehandlers() checks each ECFLAGS_* bit before acting, so it is safe to call regardless of how far ecinstallhandlers() progressed:

-ENODEV (handler not installed): only calls acpiecstop() -EPROBE_DEFER (handler installed): removes handler, stops EC(CVE-2026-31426)