OESA-2026-2496 (CVE-2025-22077)

Vulnerability from osv_openeuler – Published: 2026-05-29 11:11 – Updated: 2026-08-06 11:11 – Source website
VLAI
Summary
kernel security update
Details

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 FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync() in tcp_close() stops all timers for the socket.

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

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->sk_net_refcnt 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->sk_net_refcnt == 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 sock_lock_init_class_and_name(). [2]

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

Note that now we can use sk_net_refcnt_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 cifs_fill_dirent

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 cifs_fill_dirent+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> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+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 ORIG_RAX: 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: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30

Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+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 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: 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

skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG 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 skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags.

Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() 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)

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2605.5.0.0374.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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 \u0026quot;smb: client: fix TCP timers deadlock after rmmod\u0026quot;\n\nThis reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.\n\nCommit e9f2517a3e18 (\u0026quot;smb: client: fix TCP timers deadlock after\nrmmod\u0026quot;) 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 (\u0026quot;smb: client:\nFix use-after-free of network namespace.\u0026quot;) 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-\u0026gt;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\u0026apos;s why I converted the CIFS client socket to have a reference to\nnetns (sk-\u0026gt;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\u0026apos;s revert the bogus fix.\n\nNote that now we can use sk_net_refcnt_upgrade() for the socket\nconversion, but I\u0026apos;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  \u0026lt;TASK\u0026gt;\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 \u0026lt;48\u0026gt; 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  \u0026lt;/TASK\u0026gt;\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 \u0026gt;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\u0026apos;s linear data rather than transferring frag descriptors.(CVE-2026-43503)",
  "id": "OESA-2026-2496",
  "modified": "2026-08-06T11:11:27Z",
  "published": "2026-05-29T11:11:27Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2025-22077",
    "CVE-2025-38051",
    "CVE-2026-43033",
    "CVE-2026-43493",
    "CVE-2026-43503"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.