{"schema_version":"1.7.2","id":"OESA-2026-2496","modified":"2026-05-29T13:34:57Z","published":"2026-05-29T13:34:57Z","upstream":["CVE-2025-22077","CVE-2025-38051","CVE-2026-43033","CVE-2026-43493","CVE-2026-43503"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert "smb: client: fix TCP timers deadlock after rmmod"\n\nThis reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.\n\nCommit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after\nrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is\nmentioned as CVE-2024-54680, but is actually did not fix anything;\nThe issue can be reproduced on top of it. [0]\n\nAlso, it reverted the change by commit ef7134c7fc48 ("smb: client:\nFix use-after-free of network namespace.") and introduced a real\nissue by reviving the kernel TCP socket.\n\nWhen a reconnect happens for a CIFS connection, the socket state\ntransitions to FIN_WAIT_1.  Then, inet_csk_clear_xmit_timers_sync()\nin tcp_close() stops all timers for the socket.\n\nIf an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1\nforever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.\n\nUsually, FIN can be retransmitted by the peer, but if the peer aborts\nthe connection, the issue comes into reality.\n\nI warned about this privately by pointing out the exact report [1],\nbut the bogus fix was finally merged.\n\nSo, we should not stop the timers to finally kill the connection on\nour side in that case, meaning we must not use a kernel socket for\nTCP whose sk->sk_net_refcnt is 0.\n\nThe kernel socket does not have a reference to its netns to make it\npossible to tear down netns without cleaning up every resource in it.\n\nFor example, tunnel devices use a UDP socket internally, but we can\ndestroy netns without removing such devices and let it complete\nduring exit.  Otherwise, netns would be leaked when the last application\ndied.\n\nHowever, this is problematic for TCP sockets because TCP has timers to\nclose the connection gracefully even after the socket is close()d.  The\nlifetime of the socket and its netns is different from the lifetime of\nthe underlying connection.\n\nIf the socket user does not maintain the netns lifetime, the timer could\nbe fired after the socket is close()d and its netns is freed up, resulting\nin use-after-free.\n\nActually, we have seen so many similar issues and converted such sockets\nto have a reference to netns.\n\nThat's why I converted the CIFS client socket to have a reference to\nnetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope\nof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right\nfix**.\n\nRegarding the LOCKDEP issue, we can prevent the module unload by\nbumping the module refcount when switching the LOCKDDEP key in\nsock_lock_init_class_and_name(). [2]\n\nFor a while, let's revert the bogus fix.\n\nNote that now we can use sk_net_refcnt_upgrade() for the socket\nconversion, but I'll do so later separately to make backport easy.(CVE-2025-22077)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free in cifs_fill_dirent\n\nThere is a race condition in the readdir concurrency process, which may\naccess the rsp buffer after it has been released, triggering the\nfollowing KASAN warning.\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs]\n Read of size 4 at addr ffff8880099b819c by task a.out/342975\n\n CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full)\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x53/0x70\n  print_report+0xce/0x640\n  kasan_report+0xb8/0xf0\n  cifs_fill_dirent+0xb03/0xb60 [cifs]\n  cifs_readdir+0x12cb/0x3190 [cifs]\n  iterate_dir+0x1a1/0x520\n  __x64_sys_getdents+0x134/0x220\n  do_syscall_64+0x4b/0x110\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f996f64b9f9\n Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89\n f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\n f0 ff ff  0d f7 c3 0c 00 f7 d8 64 89 8\n RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e\n RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88\n R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000\n  </TASK>\n\n Allocated by task 408:\n  kasan_save_stack+0x20/0x40\n  kasan_save_track+0x14/0x30\n  __kasan_slab_alloc+0x6e/0x70\n  kmem_cache_alloc_noprof+0x117/0x3d0\n  mempool_alloc_noprof+0xf2/0x2c0\n  cifs_buf_get+0x36/0x80 [cifs]\n  allocate_buffers+0x1d2/0x330 [cifs]\n  cifs_demultiplex_thread+0x22b/0x2690 [cifs]\n  kthread+0x394/0x720\n  ret_from_fork+0x34/0x70\n  ret_from_fork_asm+0x1a/0x30\n\n Freed by task 342979:\n  kasan_save_stack+0x20/0x40\n  kasan_save_track+0x14/0x30\n  kasan_save_free_info+0x3b/0x60\n  __kasan_slab_free+0x37/0x50\n  kmem_cache_free+0x2b8/0x500\n  cifs_buf_release+0x3c/0x70 [cifs]\n  cifs_readdir+0x1c97/0x3190 [cifs]\n  iterate_dir+0x1a1/0x520\n  __x64_sys_getdents64+0x134/0x220\n  do_syscall_64+0x4b/0x110\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n The buggy address belongs to the object at ffff8880099b8000\n  which belongs to the cache cifs_request of size 16588\n The buggy address is located 412 bytes inside of\n  freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc)\n\n The buggy address belongs to the physical page:\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8\n head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n anon flags: 0x80000000000040(head|node=0|zone=1)\n page_type: f5(slab)\n raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001\n head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000\n head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff\n head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n  ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                             ^\n  ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ==================================================================\n\nPOC is available in the link [1].\n\nThe problem triggering process is as follows:\n\nProcess 1                       Process 2\n-----------------------------------\n---truncated---(CVE-2025-38051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption\n\nWhen decrypting data that is not in-place (src != dst), there is\nno need to save the high-order sequence bits in dst as it could\nsimply be re-copied from the source.\n\nHowever, the data to be hashed need to be rearranged accordingly.\n\n\nThanks,(CVE-2026-43033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Fix handling of MAY_BACKLOG requests\n\nMAY_BACKLOG requests can return EBUSY.  Handle them by checking\nfor that value and filtering out EINPROGRESS notifications.(CVE-2026-43493)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: skbuff: preserve shared-frag marker during coalescing\n\nskb_try_coalesce() can attach paged frags from @from to @to.  If @from\nhas SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same\nexternally-owned or page-cache-backed frags, but the shared-frag marker\nis currently lost.\n\nThat breaks the invariant relied on by later in-place writers.  In\nparticular, ESP input checks skb_has_shared_frag() before deciding\nwhether an uncloned nonlinear skb can skip skb_cow_data().  If TCP\nreceive coalescing has moved shared frags into an unmarked skb, ESP can\nsee skb_has_shared_frag() as false and decrypt in place over page-cache\nbacked frags.\n\nPropagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged\nfrags.  The tailroom copy path does not need the marker because it copies\nbytes into @to's linear data rather than transferring frag descriptors.(CVE-2026-43503)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2605.5.0.0374.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","perf-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2605.5.0.0374.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","perf-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2605.5.0.0374.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2496"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43493"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-43503"}],"database_specific":{"severity":"Critical"}}