GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2025-1161 (CVE-2024-26689)

Vulnerability from osv_openeuler – Published: 2025-02-21 11:08 – Updated: 2026-08-06 11:08 – 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:

ceph: prevent use-after-free in encode_cap_msg()

In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed.

In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it.

encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.(CVE-2024-26689)

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

xsk: fix OOB map writes when deleting elements

Jordy says:

" In the xsk_map_delete_elem function an unsigned integer (map->max_entries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->max_entries can bypass the intended bounds check:

if (k >= map->max_entries)
    return -EINVAL;

This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xsk_map[k], which results in an out-of-bounds access.

spin_lock_bh(&m->lock);
map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry
old_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write
if (old_xs)
    xsk_map_sock_delete(old_xs, map_entry);
spin_unlock_bh(&m->lock);

The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead to further memory corruption. "

It indeed results in following splat:

[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: error_code(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331] <TASK> [76613.048468] ? __die+0x20/0x60 [76613.051581] ? page_fault_oops+0x15a/0x450 [76613.055747] ? search_extable+0x22/0x30 [76613.059649] ? search_bpf_extables+0x5f/0x80 [76613.063988] ? exc_page_fault+0xa9/0x140 [76613.067975] ? asm_exc_page_fault+0x22/0x30 [76613.072229] ? xsk_map_delete_elem+0x2d/0x60 [76613.076573] ? xsk_map_delete_elem+0x23/0x60 [76613.080914] __sys_bpf+0x19b7/0x23c0 [76613.084555] __x64_sys_bpf+0x1a/0x20 [76613.088194] do_syscall_64+0x37/0xb0 [76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000 [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8 [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00 ---truncated---(CVE-2024-56614)

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

netfilter: x_tables: fix LED ID check in led_tg_check()

Syzbot has reported the following BUG detected by KASAN:

BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 _syssendmsg+0x52a/0x7e0 ? pfx_sys_sendmsg+0x10/0x10 sys_sendmsg+0x292/0x380 ? __pfxsyssendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK>

Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further.(CVE-2024-56650)

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

selinux: ignore unknown extended permissions

When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels.(CVE-2024-57931)

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

netfilter: conntrack: clamp maximum hashtable size to INT_MAX

Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset. See:

0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from init_netns.(CVE-2025-21648)

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

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2502.3.0.0316.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2502.3.0.0316.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2502.3.0.0316.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-2502.3.0.0316.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nceph: prevent use-after-free in encode_cap_msg()\n\nIn fs/ceph/caps.c, in encode_cap_msg(), \u0026quot;use after free\u0026quot; error was\ncaught by KASAN at this line - \u0026apos;ceph_buffer_get(arg-\u0026gt;xattr_buf);\u0026apos;. This\nimplies before the refcount could be increment here, it was freed.\n\nIn same file, in \u0026quot;handle_cap_grant()\u0026quot; refcount is decremented by this\nline - \u0026apos;ceph_buffer_put(ci-\u0026gt;i_xattrs.blob);\u0026apos;. It appears that a race\noccurred and resource was freed by the latter line before the former\nline could increment it.\n\nencode_cap_msg() is called by __send_cap() and __send_cap() is called by\nceph_check_caps() after calling __prep_cap(). __prep_cap() is where\narg-\u0026gt;xattr_buf is assigned to ci-\u0026gt;i_xattrs.blob. This is the spot where\nthe refcount must be increased to prevent \u0026quot;use after free\u0026quot; error.(CVE-2024-26689)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxsk: fix OOB map writes when deleting elements\n\nJordy says:\n\n\u0026quot;\nIn the xsk_map_delete_elem function an unsigned integer\n(map-\u0026gt;max_entries) is compared with a user-controlled signed integer\n(k). Due to implicit type conversion, a large unsigned value for\nmap-\u0026gt;max_entries can bypass the intended bounds check:\n\n\tif (k \u0026gt;= map-\u0026gt;max_entries)\n\t\treturn -EINVAL;\n\nThis allows k to hold a negative value (between -2147483648 and -2),\nwhich is then used as an array index in m-\u0026gt;xsk_map[k], which results\nin an out-of-bounds access.\n\n\tspin_lock_bh(\u0026amp;m-\u0026gt;lock);\n\tmap_entry = \u0026amp;m-\u0026gt;xsk_map[k]; // Out-of-bounds map_entry\n\told_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write\n\tif (old_xs)\n\t\txsk_map_sock_delete(old_xs, map_entry);\n\tspin_unlock_bh(\u0026amp;m-\u0026gt;lock);\n\nThe xchg operation can then be used to cause an out-of-bounds write.\nMoreover, the invalid map_entry passed to xsk_map_sock_delete can lead\nto further memory corruption.\n\u0026quot;\n\nIt indeed results in following splat:\n\n[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108\n[76612.904330] #PF: supervisor write access in kernel mode\n[76612.909639] #PF: error_code(0x0002) - not-present page\n[76612.914855] PGD 0 P4D 0\n[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP\n[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470\n[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60\n[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff \u0026lt;48\u0026gt; 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31\n[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246\n[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000\n[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000\n[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007\n[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8\n[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0\n[76613.005303] FS:  00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000\n[76613.013517] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0\n[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[76613.041086] PKRU: 55555554\n[76613.043842] Call Trace:\n[76613.046331]  \u0026lt;TASK\u0026gt;\n[76613.048468]  ? __die+0x20/0x60\n[76613.051581]  ? page_fault_oops+0x15a/0x450\n[76613.055747]  ? search_extable+0x22/0x30\n[76613.059649]  ? search_bpf_extables+0x5f/0x80\n[76613.063988]  ? exc_page_fault+0xa9/0x140\n[76613.067975]  ? asm_exc_page_fault+0x22/0x30\n[76613.072229]  ? xsk_map_delete_elem+0x2d/0x60\n[76613.076573]  ? xsk_map_delete_elem+0x23/0x60\n[76613.080914]  __sys_bpf+0x19b7/0x23c0\n[76613.084555]  __x64_sys_bpf+0x1a/0x20\n[76613.088194]  do_syscall_64+0x37/0xb0\n[76613.091832]  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[76613.096962] RIP: 0033:0x7f80b6d1e88d\n[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48\n[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141\n[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d\n[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003\n[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000\n[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8\n[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00\n---truncated---(CVE-2024-56614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: fix LED ID check in led_tg_check()\n\nSyzbot has reported the following BUG detected by KASAN:\n\nBUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70\nRead of size 1 at addr ffff8881022da0c8 by task repro/5879\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x241/0x360\n ? __pfx_dump_stack_lvl+0x10/0x10\n ? __pfx__printk+0x10/0x10\n ? _printk+0xd5/0x120\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n print_report+0x169/0x550\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x183/0x530\n ? __virt_addr_valid+0x45f/0x530\n ? __phys_addr+0xba/0x170\n ? strlen+0x58/0x70\n kasan_report+0x143/0x180\n ? strlen+0x58/0x70\n strlen+0x58/0x70\n kstrdup+0x20/0x80\n led_tg_check+0x18b/0x3c0\n xt_check_target+0x3bb/0xa40\n ? __pfx_xt_check_target+0x10/0x10\n ? stack_depot_save_flags+0x6e4/0x830\n ? nft_target_init+0x174/0xc30\n nft_target_init+0x82d/0xc30\n ? __pfx_nft_target_init+0x10/0x10\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? rcu_is_watching+0x15/0xb0\n ? nf_tables_newrule+0x1609/0x2980\n ? nf_tables_newrule+0x1609/0x2980\n ? __kmalloc_noprof+0x21a/0x400\n nf_tables_newrule+0x1860/0x2980\n ? __pfx_nf_tables_newrule+0x10/0x10\n ? __nla_parse+0x40/0x60\n nfnetlink_rcv+0x14e5/0x2ab0\n ? __pfx_validate_chain+0x10/0x10\n ? __pfx_nfnetlink_rcv+0x10/0x10\n ? __lock_acquire+0x1384/0x2050\n ? netlink_deliver_tap+0x2e/0x1b0\n ? __pfx_lock_release+0x10/0x10\n ? netlink_deliver_tap+0x2e/0x1b0\n netlink_unicast+0x7f8/0x990\n ? __pfx_netlink_unicast+0x10/0x10\n ? __virt_addr_valid+0x183/0x530\n ? __check_object_size+0x48e/0x900\n netlink_sendmsg+0x8e4/0xcb0\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? aa_sock_msg_perm+0x91/0x160\n ? __pfx_netlink_sendmsg+0x10/0x10\n __sock_sendmsg+0x223/0x270\n ____sys_sendmsg+0x52a/0x7e0\n ? __pfx_____sys_sendmsg+0x10/0x10\n __sys_sendmsg+0x292/0x380\n ? __pfx___sys_sendmsg+0x10/0x10\n ? lockdep_hardirqs_on_prepare+0x43d/0x780\n ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10\n ? exc_page_fault+0x590/0x8c0\n ? do_syscall_64+0xb6/0x230\n do_syscall_64+0xf3/0x230\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n \u0026lt;/TASK\u0026gt;\n\nSince an invalid (without \u0026apos;\\0\u0026apos; byte at all) byte sequence may be passed\nfrom userspace, add an extra check to ensure that such a sequence is\nrejected as possible ID and so never passed to \u0026apos;kstrdup()\u0026apos; and further.(CVE-2024-56650)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nselinux: ignore unknown extended permissions\n\nWhen evaluating extended permissions, ignore unknown permissions instead\nof calling BUG(). This commit ensures that future permissions can be\nadded without interfering with older kernels.(CVE-2024-57931)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: clamp maximum hashtable size to INT_MAX\n\nUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, it\nis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when\nresizing hashtable because __GFP_NOWARN is unset. See:\n\n  0708a0afe291 (\u0026quot;mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls\u0026quot;)\n\nNote: hashtable resize is only possible from init_netns.(CVE-2025-21648)",
  "id": "OESA-2025-1161",
  "modified": "2026-08-06T11:08:15Z",
  "published": "2025-02-21T11:08:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1161"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26689"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56614"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56650"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57931"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21648"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-26689",
    "CVE-2024-56614",
    "CVE-2024-56650",
    "CVE-2024-57931",
    "CVE-2025-21648"
  ]
}



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.