OESA-2026-2496

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

Revert "smb: client: fix TCP timers deadlock after rmmod"

This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.

Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is mentioned as CVE-2024-54680, but is actually did not fix anything; The issue can be reproduced on top of it. [0]

Also, it reverted the change by commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") and introduced a real issue by reviving the kernel TCP socket.

When a reconnect happens for a CIFS connection, the socket state transitions to FINWAIT1. Then, inetcskclearxmittimerssync() in tcpclose() stops all timers for the socket.

If an incoming FIN packet is lost, the socket will stay at FINWAIT1 forever, and such sockets could be leaked up to net.ipv4.tcpmaxorphans.

Usually, FIN can be retransmitted by the peer, but if the peer aborts the connection, the issue comes into reality.

I warned about this privately by pointing out the exact report [1], but the bogus fix was finally merged.

So, we should not stop the timers to finally kill the connection on our side in that case, meaning we must not use a kernel socket for TCP whose sk->sknetrefcnt is 0.

The kernel socket does not have a reference to its netns to make it possible to tear down netns without cleaning up every resource in it.

For example, tunnel devices use a UDP socket internally, but we can destroy netns without removing such devices and let it complete during exit. Otherwise, netns would be leaked when the last application died.

However, this is problematic for TCP sockets because TCP has timers to close the connection gracefully even after the socket is close()d. The lifetime of the socket and its netns is different from the lifetime of the underlying connection.

If the socket user does not maintain the netns lifetime, the timer could be fired after the socket is close()d and its netns is freed up, resulting in use-after-free.

Actually, we have seen so many similar issues and converted such sockets to have a reference to netns.

That's why I converted the CIFS client socket to have a reference to netns (sk->sknetrefcnt == 1), which is somehow mentioned as out-of-scope of CIFS and technically wrong in e9f2517a3e18, but is in-scope and right fix.

Regarding the LOCKDEP issue, we can prevent the module unload by bumping the module refcount when switching the LOCKDDEP key in socklockinitclassand_name(). [2]

For a while, let's revert the bogus fix.

Note that now we can use sknetrefcnt_upgrade() for the socket conversion, but I'll do so later separately to make backport easy.(CVE-2025-22077)

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

smb: client: Fix use-after-free in cifsfilldirent

There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning.

================================================================== BUG: KASAN: slab-use-after-free in cifsfilldirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975

CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xce/0x640 kasanreport+0xb8/0xf0 cifsfilldirent+0xb03/0xb60 [cifs] cifsreaddir+0x12cb/0x3190 [cifs] iteratedir+0x1a1/0x520 _x64sysgetdents+0x134/0x220 dosyscall64+0x4b/0x110 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIGRAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK>

Allocated by task 408: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 _kasanslaballoc+0x6e/0x70 kmemcacheallocnoprof+0x117/0x3d0 mempoolallocnoprof+0xf2/0x2c0 cifsbufget+0x36/0x80 [cifs] allocatebuffers+0x1d2/0x330 [cifs] cifsdemultiplexthread+0x22b/0x2690 [cifs] kthread+0x394/0x720 retfromfork+0x34/0x70 retfromforkasm+0x1a/0x30

Freed by task 342979: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasansavefree_info+0x3b/0x60 __kasanslabfree+0x37/0x50 kmemcachefree+0x2b8/0x500 cifsbufrelease+0x3c/0x70 [cifs] cifsreaddir+0x1c97/0x3190 [cifs] iteratedir+0x1a1/0x520 __x64sysgetdents64+0x134/0x220 dosyscall64+0x4b/0x110 entrySYSCALL64afterhwframe+0x76/0x7e

The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) pagetype: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================

POC is available in the link [1].

The problem triggering process is as follows:

Process 1 Process 2

---truncated---(CVE-2025-38051)

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

crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption

When decrypting data that is not in-place (src != dst), there is no need to save the high-order sequence bits in dst as it could simply be re-copied from the source.

However, the data to be hashed need to be rearranged accordingly.

Thanks,(CVE-2026-43033)

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

crypto: pcrypt - Fix handling of MAY_BACKLOG requests

MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.(CVE-2026-43493)

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

net: skbuff: preserve shared-frag marker during coalescing

skbtrycoalesce() can attach paged frags from @from to @to. If @from has SKBFLSHAREDFRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost.

That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skbhassharedfrag() before deciding whether an uncloned nonlinear skb can skip skbcowdata(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skbhassharedfrag() as false and decrypt in place over page-cache backed frags.

Propagate SKBFLSHAREDFRAG when skbtrycoalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.(CVE-2026-43503)