GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
oesa-2026-1306
Vulnerability from osv_openeuler
Published
2026-02-06 11:10
Modified
2026-08-06 11:10
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:

cacheinfo: Fix shared_cpu_map to handle shared caches at different levels

The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs.

CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3

This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)

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

drm/radeon: Fix integer overflow in radeon_cs_parser_init

The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later(CVE-2023-53309)

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

media: v4l2-mem2mem: add lock to protect parameter num_rdy

Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.

kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&]

kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3:  v4l2_m2m_buf_queue+0xd8/0x10c(CVE-2023-53519)

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

wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex

Apparently the hex passphrase mechanism does not work on newer chips/firmware (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid the hexification.

OpenBSD has been doing it like this from the beginning, so this should work on all chips.

Also clear the structure before setting the PMK. This was leaking uninitialized stack contents to the device.(CVE-2023-53715)

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

usb-storage: alauda: Fix uninit-value in alauda_check_media()

Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage:

BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460

The problem is that alauda_check_media() doesn't verify that its USB transfer succeeded before trying to use the received data. What should happen if the transfer fails isn't entirely clear, but a reasonably conservative approach is to pretend that no media is present.

A similar problem exists in a usb_stor_dbg() call in alauda_get_media_status(). In this case, when an error occurs the call is redundant, because usb_stor_ctrl_transfer() already will print a debugging message.

Finally, unrelated to the uninitialized memory access, is the fact that alauda_check_media() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this. We'll use it instead.(CVE-2023-53847)

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

RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()

The ucmd->log_sq_bb_count variable is controlled by the user so this shift can wrap. Fix it by using check_shl_overflow() in the same way that it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined behavior in hns_roce_set_user_sq_size()").(CVE-2023-54168)

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

usb: typec: altmodes/displayport: fix pin_assignment_show

This patch fixes negative indexing of buf array in pin_assignment_show when get_current_pin_assignments returns 0 i.e. no compatible pin assignments are found.

BUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c ... Call trace: dump_backtrace+0x110/0x204 dump_stack_lvl+0x84/0xbc print_report+0x358/0x974 kasan_report+0x9c/0xfc __do_kernel_fault+0xd4/0x2d4 do_bad_area+0x48/0x168 do_tag_check_fault+0x24/0x38 do_mem_abort+0x6c/0x14c el1_abort+0x44/0x68 el1h_64_sync_handler+0x64/0xa4 el1h_64_sync+0x78/0x7c pin_assignment_show+0x26c/0x33c dev_attr_show+0x50/0xc0(CVE-2023-54186)

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

md/raid10: fix memleak of md thread

In raid10_run(), if setup_conf() succeed and raid10_run() failed before setting 'mddev->thread', then in the error path 'conf->thread' is not freed.

Fix the problem by setting 'mddev->thread' right after setup_conf().(CVE-2023-54294)

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

dm flakey: don't corrupt the zero page

When we need to zero some range on a block device, the function __blkdev_issue_zero_pages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory.

Fix this bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case.(CVE-2023-54317)

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

clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns

What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to.

clone_private_mnt() checks the former, but not the latter.

There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above.(CVE-2025-38499)

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

ipv6: reject malicious packets in ipv6_gso_segment()

syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.

This 16bit field has a limited range.

Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment()

WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)

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

vsock: Do not allow binding to VMADDR_PORT_ANY

It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).

Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY.(CVE-2025-38618)

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

pid: Add a judgment for ns null in pid_nr_ns

__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {

Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.

For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)

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

fs/proc: fix uaf in proc_readdir_de()

Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.

We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:

1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;

2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;

3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.

CPU 0 | CPU 1

traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |

rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)

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-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2602.1.0.0361.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2602.1.0.0361.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2602.1.0.0361.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-2602.1.0.0361.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\ncacheinfo: Fix shared_cpu_map to handle shared caches at different levels\n\nThe cacheinfo sets up the shared_cpu_map by checking whether the caches\nwith the same index are shared between CPUs. However, this will trigger\nslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.\nAnother problem is the mismatched shared_cpu_map when the shared cache does\nnot have the same index between CPUs.\n\nCPU0\tI\tD\tL3\nindex\t0\t1\t2\tx\n\t^\t^\t^\t^\nindex\t0\t1\t2\t3\nCPU1\tI\tD\tL2\tL3\n\nThis patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: Fix integer overflow in radeon_cs_parser_init\n\nThe type of size is unsigned, if size is 0x40000000, there will be an\ninteger overflow, size will be zero after size *= sizeof(uint32_t),\nwill cause uninitialized memory to be referenced later(CVE-2023-53309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: v4l2-mem2mem: add lock to protect parameter num_rdy\n\nGetting below error when using KCSAN to check the driver. Adding lock to\nprotect parameter num_rdy when getting the value with function:\nv4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.\n\nkworker/u16:3: [name:report\u0026amp;]BUG: KCSAN: data-race in v4l2_m2m_buf_queue\nkworker/u16:3: [name:report\u0026amp;]\n\nkworker/u16:3: [name:report\u0026amp;]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:\nkworker/u16:3:\u00a0 v4l2_m2m_buf_queue+0xd8/0x10c(CVE-2023-53519)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex\n\nApparently the hex passphrase mechanism does not work on newer\nchips/firmware (e.g. BCM4387). It seems there was a simple way of\npassing it in binary all along, so use that and avoid the hexification.\n\nOpenBSD has been doing it like this from the beginning, so this should\nwork on all chips.\n\nAlso clear the structure before setting the PMK. This was leaking\nuninitialized stack contents to the device.(CVE-2023-53715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb-storage: alauda: Fix uninit-value in alauda_check_media()\n\nSyzbot got KMSAN to complain about access to an uninitialized value in\nthe alauda subdriver of usb-storage:\n\nBUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0\ndrivers/usb/storage/alauda.c:1137\nCPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nCall Trace:\n  __dump_stack lib/dump_stack.c:77 [inline]\n  dump_stack+0x191/0x1f0 lib/dump_stack.c:113\n  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108\n  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250\n  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460\n\nThe problem is that alauda_check_media() doesn\u0026apos;t verify that its USB\ntransfer succeeded before trying to use the received data.  What\nshould happen if the transfer fails isn\u0026apos;t entirely clear, but a\nreasonably conservative approach is to pretend that no media is\npresent.\n\nA similar problem exists in a usb_stor_dbg() call in\nalauda_get_media_status().  In this case, when an error occurs the\ncall is redundant, because usb_stor_ctrl_transfer() already will print\na debugging message.\n\nFinally, unrelated to the uninitialized memory access, is the fact\nthat alauda_check_media() performs DMA to a buffer on the stack.\nFortunately usb-storage provides a general purpose DMA-able buffer for\nuses like this.  We\u0026apos;ll use it instead.(CVE-2023-53847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Prevent shift wrapping in set_user_sq_size()\n\nThe ucmd-\u0026gt;log_sq_bb_count variable is controlled by the user so this\nshift can wrap.  Fix it by using check_shl_overflow() in the same way\nthat it was done in commit 515f60004ed9 (\u0026quot;RDMA/hns: Prevent undefined\nbehavior in hns_roce_set_user_sq_size()\u0026quot;).(CVE-2023-54168)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: altmodes/displayport: fix pin_assignment_show\n\nThis patch fixes negative indexing of buf array in pin_assignment_show\nwhen get_current_pin_assignments returns 0 i.e. no compatible pin\nassignments are found.\n\nBUG: KASAN: use-after-free in pin_assignment_show+0x26c/0x33c\n...\nCall trace:\ndump_backtrace+0x110/0x204\ndump_stack_lvl+0x84/0xbc\nprint_report+0x358/0x974\nkasan_report+0x9c/0xfc\n__do_kernel_fault+0xd4/0x2d4\ndo_bad_area+0x48/0x168\ndo_tag_check_fault+0x24/0x38\ndo_mem_abort+0x6c/0x14c\nel1_abort+0x44/0x68\nel1h_64_sync_handler+0x64/0xa4\nel1h_64_sync+0x78/0x7c\npin_assignment_show+0x26c/0x33c\ndev_attr_show+0x50/0xc0(CVE-2023-54186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix memleak of md thread\n\nIn raid10_run(), if setup_conf() succeed and raid10_run() failed before\nsetting \u0026apos;mddev-\u0026gt;thread\u0026apos;, then in the error path \u0026apos;conf-\u0026gt;thread\u0026apos; is not\nfreed.\n\nFix the problem by setting \u0026apos;mddev-\u0026gt;thread\u0026apos; right after setup_conf().(CVE-2023-54294)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm flakey: don\u0026apos;t corrupt the zero page\n\nWhen we need to zero some range on a block device, the function\n__blkdev_issue_zero_pages submits a write bio with the bio vector pointing\nto the zero page. If we use dm-flakey with corrupt bio writes option, it\nwill corrupt the content of the zero page which results in crashes of\nvarious userspace programs. Glibc assumes that memory returned by mmap is\nzeroed and it uses it for calloc implementation; if the newly mapped\nmemory is not zeroed, calloc will return non-zeroed memory.\n\nFix this bug by testing if the page is equal to ZERO_PAGE(0) and\navoiding the corruption in this case.(CVE-2023-54317)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns\n\nWhat we want is to verify there is that clone won\u0026apos;t expose something\nhidden by a mount we wouldn\u0026apos;t be able to undo.  \u0026quot;Wouldn\u0026apos;t be able to undo\u0026quot;\nmay be a result of MNT_LOCKED on a child, but it may also come from\nlacking admin rights in the userns of the namespace mount belongs to.\n\nclone_private_mnt() checks the former, but not the latter.\n\nThere\u0026apos;s a number of rather confusing CAP_SYS_ADMIN checks in various\nuserns during the mount, especially with the new mount API; they serve\ndifferent purposes and in case of clone_private_mnt() they usually,\nbut not always end up covering the missing check mentioned above.(CVE-2025-38499)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: reject malicious packets in ipv6_gso_segment()\n\nsyzbot was able to craft a packet with very long IPv6 extension headers\nleading to an overflow of skb-\u0026gt;transport_header.\n\nThis 16bit field has a limited range.\n\nAdd skb_reset_transport_header_careful() helper and use it\nfrom ipv6_gso_segment()\n\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nModules linked in:\nCPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\n RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\n RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n  nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110\n  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n  __skb_gso_segment+0x342/0x510 net/core/gso.c:124\n  skb_gso_segment include/net/gso.h:83 [inline]\n  validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950\n  validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000\n  sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329\n  __dev_xmit_skb net/core/dev.c:4102 [inline]\n  __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Do not allow binding to VMADDR_PORT_ANY\n\nIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This can\ncause a use-after-free when a connection is made to the bound socket.\nThe socket returned by accept() also has port VMADDR_PORT_ANY but is not\non the list of unbound sockets. Binding it will result in an extra\nrefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep\nthe binding until socket destruction).\n\nModify the check in __vsock_bind_connectible() to also prevent binding\nto VMADDR_PORT_ANY.(CVE-2025-38618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npid: Add a judgment for ns null in pid_nr_ns\n\n__task_pid_nr_ns\n        ns = task_active_pid_ns(current);\n        pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);\n                if (pid \u0026amp;\u0026amp; ns-\u0026gt;level \u0026lt;= pid-\u0026gt;level) {\n\nSometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.\n\nFor example:\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n\tMem abort info:\n\tESR = 0x0000000096000007\n\tEC = 0x25: DABT (current EL), IL = 32 bits\n\tSET = 0, FnV = 0\n\tEA = 0, S1PTW = 0\n\tFSC = 0x07: level 3 translation fault\n\tData abort info:\n\tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n\tCM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000\n\t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000\n\tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : __task_pid_nr_ns+0x74/0xd0\n\tlr : __task_pid_nr_ns+0x24/0xd0\n\tsp : ffffffc08001bd10\n\tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001\n\tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31\n\tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0\n\tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000\n\tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc\n\tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800\n\tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001\n\tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449\n\tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc\n\tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0\n\tCall trace:\n\t__task_pid_nr_ns+0x74/0xd0\n\t...\n\t__handle_irq_event_percpu+0xd4/0x284\n\thandle_irq_event+0x48/0xb0\n\thandle_fasteoi_irq+0x160/0x2d8\n\tgeneric_handle_domain_irq+0x44/0x60\n\tgic_handle_irq+0x4c/0x114\n\tcall_on_irq_stack+0x3c/0x74\n\tdo_interrupt_handler+0x4c/0x84\n\tel1_interrupt+0x34/0x58\n\tel1h_64_irq_handler+0x18/0x24\n\tel1h_64_irq+0x68/0x6c\n\taccount_kernel_stack+0x60/0x144\n\texit_task_stack_account+0x1c/0x80\n\tdo_exit+0x7e4/0xaf8\n\t...\n\tget_signal+0x7bc/0x8d8\n\tdo_notify_resume+0x128/0x828\n\tel0_svc+0x6c/0x70\n\tel0t_64_sync_handler+0x68/0xbc\n\tel0t_64_sync+0x1a8/0x1ac\n\tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access.  We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time.  The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n   pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n   them from rbtree.  erase tun3 first, and then erase tun2.  the\n   pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n   pde(tun2) which is released, it will case uaf access.\n\nCPU 0                                      |    CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/      |   unregister_netdevice(tun-\u0026gt;dev)   //tun3 tun2\nsys_getdents64()                           |\n  iterate_dir()                            |\n    proc_readdir()                         |\n      proc_readdir_de()                    |     snmp6_unregister_dev()\n        pde_get(de);                       |       proc_remove()\n        read_unlock(\u0026amp;proc_subdir_lock);    |         remove_proc_subtree()\n                                           |           write_lock(\u0026amp;proc_subdir_lock);\n        [time window]                      |           rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n                                           |           write_unlock(\u0026amp;proc_subdir_lock);\n        read_lock(\u0026amp;proc_subdir_lock);      |\n        next = pde_subdir_next(de);        |\n        pde_put(de);                       |\n        de = next;    //UAF                |\n\nrbtree of dev_snmp6\n                        |\n                    pde(tun3)\n                     /    \\\n                  NULL  pde(tun2)(CVE-2025-40271)",
  "id": "OESA-2026-1306",
  "modified": "2026-08-06T11:10:20Z",
  "published": "2026-02-06T11:10:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1306"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53254"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53309"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53519"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53715"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53847"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54168"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54186"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54294"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54317"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38499"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38572"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38618"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40178"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
    }
  ],
  "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-2023-53254",
    "CVE-2023-53309",
    "CVE-2023-53519",
    "CVE-2023-53715",
    "CVE-2023-53847",
    "CVE-2023-54168",
    "CVE-2023-54186",
    "CVE-2023-54294",
    "CVE-2023-54317",
    "CVE-2025-38499",
    "CVE-2025-38572",
    "CVE-2025-38618",
    "CVE-2025-40178",
    "CVE-2025-40271"
  ]
}



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.