OESA-2026-2076

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

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

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

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

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

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

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

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

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

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

powerpc/64s/slb: Fix SLB multihit issue during SLB preload

On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry.

To optimize performance, the kernel skips switchmmucontext() in switchmmirqsoff() when the prev and next mmstruct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache.

If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switchmmucontext(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error.

The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch.

CPU 0 CPU 1 ----- ----- Process P exec swapper/1 loadelfbinary beginnewexc activatemm switchmmirqsoff switchmmucontext switchslb /* * This invalidates all * the entries in the HW * and setup the new HW * SLB entries as per the * preload cache. */ contextswitch schedmigratetask migrates process P to cpu-1

Process swapper/0 context switch (to process P) (uses mmstruct of Process P) switchmmirqsoff() switchslb loadslb++ /* * loadslb becomes 0 here * and we evict an entry from * the preload cache with * preloadage(). We still * keep HW SLB and preload * cache in sync, that is * because all HW SLB entries * anyways gets evicted in * switchslb during SLBIA. * We then only add those * entries back in HW SLB, * which are currently * present in preloadcache * (after eviction). */ loadelfbinary continues... setupnewexec() slbsetupnew_exec()

                                    sched_switch event
                                    sched_migrate_task migrates
                                    process P to cpu-0

contextswitch from swapper/0 to Process P switchmmirqsoff() /* * Since both prev and next mm struct are same we don't call * switchmmucontext(). This will cause the HW SLB and SW preload * cache to go out of sync in preloadnewslbcontext. Because there * was an SLB entry which was evicted from both HW and preload cache * on cpu-1. Now later in preloadnewslbcontext(), when we will try * to add the same preload entry again, we will add this to the SW * preload cache and then will add it to the HW SLB. Since on cpu-0 * this entry was never invalidated, hence adding this entry to the HW * SLB will cause a SLB multi-hit error. */ loadelfbinary cont ---truncated---(CVE-2025-71078)

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:

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, the following vulnerability has been resolved: smb: client: fix krb5 mount with username option. Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials. It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts. By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8. So fix this by matching username mount option in match_session() even with Kerberos.(CVE-2026-31392)

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)