{"schema_version":"1.7.2","id":"OESA-2025-2632","modified":"2025-11-07T12:30:42Z","published":"2025-11-07T12:30:42Z","upstream":["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"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\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 <TASK>\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>/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)\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'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'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  --> trigger BUG_ON due to\n  unmap_poisoned_folio couldn'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 <TASK>\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->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->usbdev_intf0)\n                                        else\n                                          usb_put_dev(ictx->usbdev_intf1)\n...\nwhile\n  send_packet\n    if\n      pipe = usb_sndintpipe(\n        ictx->usbdev_intf0) UAF\n    else\n      pipe = usb_sndctrlpipe(\n        ictx->usbdev_intf0, 0) UAF\n\nGuard access to usbdev_intf0 and usbdev_intf1 after disconnect by\nchecking ictx->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->disconnected under ictx->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->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'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 (>= 2 GiB), which may lead to integer overflow.(CVE-2025-40081)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-288.0.0.191.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","perf-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-288.0.0.191.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-288.0.0.191.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","perf-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-288.0.0.191.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2632"},{"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"}],"database_specific":{"severity":"High"}}