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

gfs2: Fix possible data races in gfs2_show_options()

Some fields such as gt_logd_secs of the struct gfs2_tune are accessed without holding the lock gt_spin in gfs2_show_options():

val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val);

And thus can cause data races when gfs2_show_options() and other functions such as gfs2_reconfigure() are concurrently executed:

spin_lock(&gt->gt_spin); gt->gt_logd_secs = newargs->ar_commit;

To fix these possible data races, the lock sdp->sd_tune.gt_spin is acquired before accessing the fields of gfs2_tune and released after these accesses.

Further changes by Andreas:

  • Don't hold the spin lock over the seq_printf operations.(CVE-2023-53622)

In the Linux kernel, a vulnerability exists in the IP checksum code for arm64 architecture. Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length calls") added an early return for zero-length input, syzkaller has discovered an example of a negative length that causes an undefined shift and an out-of-bounds read. An attacker can exploit this vulnerability to read data beyond the buffer boundary, affecting system confidentiality.(CVE-2023-53726)

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

SUNRPC: make sure cache entry active before cache_show

The function c_show was called with protection from RCU. This only ensures that cp will not be freed. Therefore, the reference count for cp can drop to zero, which will trigger a refcount use-after-free warning when cache_get is called. To resolve this issue, use cache_get_rcu to ensure that cp remains active.

------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120

Call Trace: <TASK> c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53174)

In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 65536 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc $262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 2>/dev/null | hexdump -e 1/8 %u n )ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) 2>/dev/null | hexdump -e 1/8 %u n )dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 65536 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc $262144 dmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the array_cursor/damaged test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir <KERNEL_DIR>(CVE-2024-57929)

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

mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list

In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache.

Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again.

This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows:

cpu0 cpu1 shrink_folio_list memory_failure TestSetPageHWPoison unmap_poisoned_folio --> trigger BUG_ON due to unmap_poisoned_folio couldn't handle large folio

[(CVE-2025-39725)

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

i40e: add validation for ring_len param

The ring_len parameter provided by the virtual function (VF) is assigned directly to the hardware memory context (HMC) without any validation.

To address this, introduce an upper boundary check for both Tx and Rx queue lengths. The maximum number of descriptors supported by the hardware is 8k-32. Additionally, enforce alignment constraints: Tx rings must be a multiple of 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)

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

media: rc: fix races with imon_disconnect()

Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465

CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device.

Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage.

As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer.

Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1) ... while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAF

Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present.

Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations.

Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-39993)

In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)

There is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call->perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)

In the Linux kernel, a vulnerability exists in the UDF filesystem's handling of Allocation Extent Descriptors. When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read. This vulnerability was found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)

In the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)

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": [
          "kernel-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-debuginfo-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-debugsource-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-devel-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-headers-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-source-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-tools-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "kernel-tools-devel-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "perf-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "perf-debuginfo-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "python3-perf-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-288.0.0.190.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-288.0.0.190.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-debuginfo-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-debugsource-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-devel-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-headers-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-source-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-tools-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "kernel-tools-devel-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "perf-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "perf-debuginfo-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "python3-perf-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-288.0.0.190.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-288.0.0.190.oe2203sp3"
            }
          ],
          "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\ngfs2: Fix possible data races in gfs2_show_options()\n\nSome fields such as gt_logd_secs of the struct gfs2_tune are accessed\nwithout holding the lock gt_spin in gfs2_show_options():\n\n  val = sdp-\u0026gt;sd_tune.gt_logd_secs;\n  if (val != 30)\n    seq_printf(s, \u0026quot;,commit=%d\u0026quot;, val);\n\nAnd thus can cause data races when gfs2_show_options() and other functions\nsuch as gfs2_reconfigure() are concurrently executed:\n\n  spin_lock(\u0026amp;gt-\u0026gt;gt_spin);\n  gt-\u0026gt;gt_logd_secs = newargs-\u0026gt;ar_commit;\n\nTo fix these possible data races, the lock sdp-\u0026gt;sd_tune.gt_spin is\nacquired before accessing the fields of gfs2_tune and released after these\naccesses.\n\nFurther changes by Andreas:\n\n- Don\u0026apos;t hold the spin lock over the seq_printf operations.(CVE-2023-53622)\n\nIn the Linux kernel, a vulnerability exists in the IP checksum code for arm64 architecture. Although commit c2c24edb1d9c (\u0026quot;arm64: csum: Fix pathological zero-length calls\u0026quot;) added an early return for zero-length input, syzkaller has discovered an example of a negative length that causes an undefined shift and an out-of-bounds read. An attacker can exploit this vulnerability to read data beyond the buffer boundary, affecting system confidentiality.(CVE-2023-53726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: make sure cache entry active before cache_show\n\nThe function `c_show` was called with protection from RCU. This only\nensures that `cp` will not be freed. Therefore, the reference count for\n`cp` can drop to zero, which will trigger a refcount use-after-free\nwarning when `cache_get` is called. To resolve this issue, use\n`cache_get_rcu` to ensure that `cp` remains active.\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 7 PID: 822 at lib/refcount.c:25\nrefcount_warn_saturate+0xb1/0x120\nCPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb1/0x120\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n c_show+0x2fc/0x380 [sunrpc]\n seq_read_iter+0x589/0x770\n seq_read+0x1e5/0x270\n proc_reg_read+0xe1/0x140\n vfs_read+0x125/0x530\n ksys_read+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-53174)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 65536 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc $262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192  2\u0026gt;/dev/null | hexdump -e  1/8  %u n  )ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056))  2\u0026gt;/dev/null | hexdump -e  1/8  %u n  )dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 65536 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc $262144 dmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the  array_cursor/damaged  test in dm-unit:  dm-unit run /pdata/array_cursor/damaged --kernel-dir \u0026lt;KERNEL_DIR\u0026gt;(CVE-2024-57929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list\n\nIn shrink_folio_list(), the hwpoisoned folio may be large folio, which\ncan\u0026apos;t be handled by unmap_poisoned_folio().  For THP, try_to_unmap_one()\nmust be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then\nretry.  Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of\npvmw.pte.  Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a\nWARN_ON_ONCE due to the page isn\u0026apos;t in swapcache.\n\nSince UCE is rare in real world, and race with reclaimation is more rare,\njust skipping the hwpoisoned large folio is enough.  memory_failure() will\nhandle it if the UCE is triggered again.\n\nThis happens when memory reclaim for large folio races with\nmemory_failure(), and will lead to kernel panic.  The race is as\nfollows:\n\ncpu0      cpu1\n shrink_folio_list memory_failure\n  TestSetPageHWPoison\n  unmap_poisoned_folio\n  --\u0026gt; trigger BUG_ON due to\n  unmap_poisoned_folio couldn\u0026apos;t\n   handle large folio\n\n[(CVE-2025-39725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: add validation for ring_len param\n\nThe `ring_len` parameter provided by the virtual function (VF)\nis assigned directly to the hardware memory context (HMC) without\nany validation.\n\nTo address this, introduce an upper boundary check for both Tx and Rx\nqueue lengths. The maximum number of descriptors supported by the\nhardware is 8k-32.\nAdditionally, enforce alignment constraints: Tx rings must be a multiple\nof 8, and Rx rings must be a multiple of 32.(CVE-2025-39973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rc: fix races with imon_disconnect()\n\nSyzbot reports a KASAN issue as below:\nBUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]\nBUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627\nRead of size 4 at addr ffff8880256fb000 by task syz-executor314/4465\n\nCPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:317 [inline]\nprint_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433\nkasan_report+0xb1/0x1e0 mm/kasan/report.c:495\n__create_pipe include/linux/usb.h:1945 [inline]\nsend_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627\nvfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991\nvfs_write+0x2d7/0xdd0 fs/read_write.c:576\nksys_write+0x127/0x250 fs/read_write.c:631\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe iMON driver improperly releases the usb_device reference in\nimon_disconnect without coordinating with active users of the\ndevice.\n\nSpecifically, the fields usbdev_intf0 and usbdev_intf1 are not\nprotected by the users counter (ictx-\u0026gt;users). During probe,\nimon_init_intf0 or imon_init_intf1 increments the usb_device\nreference count depending on the interface. However, during\ndisconnect, usb_put_dev is called unconditionally, regardless of\nactual usage.\n\nAs a result, if vfd_write or other operations are still in\nprogress after disconnect, this can lead to a use-after-free of\nthe usb_device pointer.\n\nThread 1 vfd_write                      Thread 2 imon_disconnect\n                                        ...\n                                        if\n                                          usb_put_dev(ictx-\u0026gt;usbdev_intf0)\n                                        else\n                                          usb_put_dev(ictx-\u0026gt;usbdev_intf1)\n...\nwhile\n  send_packet\n    if\n      pipe = usb_sndintpipe(\n        ictx-\u0026gt;usbdev_intf0) UAF\n    else\n      pipe = usb_sndctrlpipe(\n        ictx-\u0026gt;usbdev_intf0, 0) UAF\n\nGuard access to usbdev_intf0 and usbdev_intf1 after disconnect by\nchecking ictx-\u0026gt;disconnected in all writer paths. Add early return\nwith -ENODEV in send_packet(), vfd_write(), lcd_write() and\ndisplay_open() if the device is no longer present.\n\nSet and read ictx-\u0026gt;disconnected under ictx-\u0026gt;lock to ensure memory\nsynchronization. Acquire the lock in imon_disconnect() before setting\nthe flag to synchronize with any ongoing operations.\n\nEnsure writers exit early and safely after disconnect before the USB\ncore proceeds with cleanup.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-39993)\n\nIn the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.(CVE-2025-40021)\n\nThere is a critical race condition in kprobe initialization in the Linux kernel that can lead to NULL pointer dereference and kernel crash.Vulnerability Analysis:The race condition occurs between kprobe activation and perf_events initialization. When CPU0 executes kprobe initialization and enables kprobe functionality, CPU1 may trigger a debug exception during this period and attempt to access the perf_events pointer that has not been initialized yet, resulting in NULL pointer dereference.Technical Details:In kernel/trace/trace_kprobe.c at line 1308, the kprobe_perf_func function attempts to access the call-\u0026gt;perf_events pointer, but due to the race condition, this pointer may not have been properly initialized.(CVE-2025-40042)\n\nIn the Linux kernel, a vulnerability exists in the UDF filesystem\u0026apos;s handling of Allocation Extent Descriptors. When parsing Allocation Extent Descriptor, lengthAllocDescs comes from on-disk data and must be validated against the block size. Crafted or corrupted images may set lengthAllocDescs so that the total descriptor length (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer, leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and trigger a KASAN use-after-free read. This vulnerability was found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-40044)\n\nIn the Linux kernel, an integer overflow vulnerability exists in the arm_spe component of the perf subsystem. The PERF_IDX2OFF() function does not properly cast to unsigned long when handling large AUX buffer sizes (\u0026gt;= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)",
  "id": "OESA-2025-2636",
  "modified": "2026-08-06T11:09:45Z",
  "published": "2025-11-07T11:09:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2636"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53622"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53174"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57929"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39973"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39993"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40042"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40044"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40081"
    }
  ],
  "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-53622",
    "CVE-2023-53726",
    "CVE-2024-53174",
    "CVE-2024-57929",
    "CVE-2025-39725",
    "CVE-2025-39973",
    "CVE-2025-39993",
    "CVE-2025-40021",
    "CVE-2025-40042",
    "CVE-2025-40044",
    "CVE-2025-40081"
  ]
}



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.