{"schema_version":"1.7.2","id":"OESA-2025-1595","modified":"2025-06-06T14:04:00Z","published":"2025-06-06T14:04:00Z","upstream":["CVE-2024-50140","CVE-2024-53175","CVE-2024-53188","CVE-2024-53200","CVE-2024-56568","CVE-2025-21676","CVE-2025-21919","CVE-2025-22028","CVE-2025-22104","CVE-2025-22109","CVE-2025-22127","CVE-2025-23161","CVE-2025-37738","CVE-2025-37747","CVE-2025-37836","CVE-2025-37903","CVE-2025-37952","CVE-2025-37988"],"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\nsched/core: Disable page allocation in task_tick_mm_cid()\n\nWith KASAN and PREEMPT_RT enabled, calling task_work_add() in\ntask_tick_mm_cid() may cause the following splat.\n\n[   63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[   63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe\n[   63.696416] preempt_count: 10001, expected: 0\n[   63.696416] RCU nest depth: 1, expected: 1\n\nThis problem is caused by the following call trace.\n\n  sched_tick() [ acquire rq-\u0026gt;__lock ]\n   -\u0026gt; task_tick_mm_cid()\n    -\u0026gt; task_work_add()\n     -\u0026gt; __kasan_record_aux_stack()\n      -\u0026gt; kasan_save_stack()\n       -\u0026gt; stack_depot_save_flags()\n        -\u0026gt; alloc_pages_mpol_noprof()\n         -\u0026gt; __alloc_pages_noprof()\n\t  -\u0026gt; get_page_from_freelist()\n\t   -\u0026gt; rmqueue()\n\t    -\u0026gt; rmqueue_pcplist()\n\t     -\u0026gt; __rmqueue_pcplist()\n\t      -\u0026gt; rmqueue_bulk()\n\t       -\u0026gt; rt_spin_lock()\n\nThe rq lock is a raw_spinlock_t. We can\u0026apos;t sleep while holding\nit. IOW, we can\u0026apos;t call alloc_pages() in stack_depot_save_flags().\n\nThe task_tick_mm_cid() function with its task_work_add() call was\nintroduced by commit 223baf9d17f2 (\u0026quot;sched: Fix performance regression\nintroduced by mm_cid\u0026quot;) in v6.4 kernel.\n\nFortunately, there is a kasan_record_aux_stack_noalloc() variant that\ncalls stack_depot_save_flags() while not allowing it to allocate\nnew pages.  To allow task_tick_mm_cid() to use task_work without\npage allocation, a new TWAF_NO_ALLOC flag is added to enable calling\nkasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()\nif set. The task_tick_mm_cid() function is modified to add this new flag.\n\nThe possible downside is the missing stack trace in a KASAN report due\nto new page allocation required when task_work_add_noallloc() is called\nwhich should be rare.(CVE-2024-50140)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipc: fix memleak if msg_init_ns failed in create_ipc_ns\n\nPercpu memory allocation may failed during create_ipc_ns however this\nfail is not handled properly since ipc sysctls and mq sysctls is not\nreleased properly. Fix this by release these two resource when failure.\n\nHere is the kmemleak stack when percpu failed:\n\nunreferenced object 0xffff88819de2a600 (size 512):\n  comm \u0026quot;shmem_2nstest\u0026quot;, pid 120711, jiffies 4300542254\n  hex dump (first 32 bytes):\n    60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff  `.........H.....\n    04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff  ........ .V.....\n  backtrace (crc be7cba35):\n    [\u0026lt;ffffffff81b43f83\u0026gt;] __kmalloc_node_track_caller_noprof+0x333/0x420\n    [\u0026lt;ffffffff81a52e56\u0026gt;] kmemdup_noprof+0x26/0x50\n    [\u0026lt;ffffffff821b2f37\u0026gt;] setup_mq_sysctls+0x57/0x1d0\n    [\u0026lt;ffffffff821b29cc\u0026gt;] copy_ipcs+0x29c/0x3b0\n    [\u0026lt;ffffffff815d6a10\u0026gt;] create_new_namespaces+0x1d0/0x920\n    [\u0026lt;ffffffff815d7449\u0026gt;] copy_namespaces+0x2e9/0x3e0\n    [\u0026lt;ffffffff815458f3\u0026gt;] copy_process+0x29f3/0x7ff0\n    [\u0026lt;ffffffff8154b080\u0026gt;] kernel_clone+0xc0/0x650\n    [\u0026lt;ffffffff8154b6b1\u0026gt;] __do_sys_clone+0xa1/0xe0\n    [\u0026lt;ffffffff843df8ff\u0026gt;] do_syscall_64+0xbf/0x1c0\n    [\u0026lt;ffffffff846000b0\u0026gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2024-53175)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix crash when unbinding\n\nIf there is an error during some initialization related to firmware,\nthe function ath12k_dp_cc_cleanup is called to release resources.\nHowever this is released again when the device is unbinded (ath12k_pci),\nand we get:\nBUG: kernel NULL pointer dereference, address: 0000000000000020\nat RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k]\nCall Trace:\nath12k_dp_cc_cleanup\nath12k_dp_free\nath12k_core_deinit\nath12k_pci_remove\n...\n\nThe issue is always reproducible from a VM because the MSI addressing\ninitialization is failing.\n\nIn order to fix the issue, just set to NULL the released structure in\nath12k_dp_cc_cleanup at the end.(CVE-2024-53188)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in hwss_setup_dpp\n\nThis commit addresses a null pointer dereference issue in\nhwss_setup_dpp(). The issue could occur when pipe_ctx-\u0026gt;plane_state is\nnull. The fix adds a check to ensure `pipe_ctx-\u0026gt;plane_state` is not null\nbefore accessing. This prevents a null pointer dereference.(CVE-2024-53200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu: Defer probe of clients after smmu device bound\n\nNull pointer dereference occurs due to a race between smmu\ndriver probe and client driver probe, when of_dma_configure()\nfor client is called after the iommu_device_register() for smmu driver\nprobe has executed but before the driver_bound() for smmu driver\nhas been called.\n\nFollowing is how the race occurs:\n\nT1:Smmu device probe\t\tT2: Client device probe\n\nreally_probe()\narm_smmu_device_probe()\niommu_device_register()\n\t\t\t\t\treally_probe()\n\t\t\t\t\tplatform_dma_configure()\n\t\t\t\t\tof_dma_configure()\n\t\t\t\t\tof_dma_configure_id()\n\t\t\t\t\tof_iommu_configure()\n\t\t\t\t\tiommu_probe_device()\n\t\t\t\t\tiommu_init_device()\n\t\t\t\t\tarm_smmu_probe_device()\n\t\t\t\t\tarm_smmu_get_by_fwnode()\n\t\t\t\t\t\tdriver_find_device_by_fwnode()\n\t\t\t\t\t\tdriver_find_device()\n\t\t\t\t\t\tnext_device()\n\t\t\t\t\t\tklist_next()\n\t\t\t\t\t\t    /* null ptr\n\t\t\t\t\t\t       assigned to smmu */\n\t\t\t\t\t/* null ptr dereference\n\t\t\t\t\t   while smmu-\u0026gt;streamid_mask */\ndriver_bound()\n\tklist_add_tail()\n\nWhen this null smmu pointer is dereferenced later in\narm_smmu_probe_device, the device crashes.\n\nFix this by deferring the probe of the client device\nuntil the smmu device has bound to the arm smmu driver.\n\n[will: Add comment](CVE-2024-56568)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fec: handle page_pool_dev_alloc_pages error\n\nThe fec_enet_update_cbd function calls page_pool_dev_alloc_pages but did\nnot handle the case when it returned NULL. There was a WARN_ON(!new_page)\nbut it would still proceed to use the NULL pointer and then crash.\n\nThis case does seem somewhat rare but when the system is under memory\npressure it can happen. One case where I can duplicate this with some\nfrequency is when writing over a smbd share to a SATA HDD attached to an\nimx6q.\n\nSetting /proc/sys/vm/min_free_kbytes to higher values also seems to solve\nthe problem for my test case. But it still seems wrong that the fec driver\nignores the memory allocation error and can crash.\n\nThis commit handles the allocation error by dropping the current packet.(CVE-2025-21676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Fix potential memory corruption in child_cfs_rq_on_list\n\nchild_cfs_rq_on_list attempts to convert a \u0026apos;prev\u0026apos; pointer to a cfs_rq.\nThis \u0026apos;prev\u0026apos; pointer can originate from struct rq\u0026apos;s leaf_cfs_rq_list,\nmaking the conversion invalid and potentially leading to memory\ncorruption. Depending on the relative positions of leaf_cfs_rq_list and\nthe task group (tg) pointer within the struct, this can cause a memory\nfault or access garbage data.\n\nThe issue arises in list_add_leaf_cfs_rq, where both\ncfs_rq-\u0026gt;leaf_cfs_rq_list and rq-\u0026gt;leaf_cfs_rq_list are added to the same\nleaf list. Also, rq-\u0026gt;tmp_alone_branch can be set to rq-\u0026gt;leaf_cfs_rq_list.\n\nThis adds a check `if (prev == \u0026amp;rq-\u0026gt;leaf_cfs_rq_list)` after the main\nconditional in child_cfs_rq_on_list. This ensures that the container_of\noperation will convert a correct cfs_rq struct.\n\nThis check is sufficient because only cfs_rqs on the same CPU are added\nto the list, so verifying the \u0026apos;prev\u0026apos; pointer against the current rq\u0026apos;s list\nhead is enough.\n\nFixes a potential memory corruption issue that due to current struct\nlayout might not be manifesting as a crash but could lead to unpredictable\nbehavior when the layout changes.(CVE-2025-21919)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vimc: skip .s_stream() for stopped entities\n\nSyzbot reported [1] a warning prompted by a check in call_s_stream()\nthat checks whether .s_stream() operation is warranted for unstarted\nor stopped subdevs.\n\nAdd a simple fix in vimc_streamer_pipeline_terminate() ensuring that\nentities skip a call to .s_stream() unless they have been previously\nproperly started.\n\n[1] Syzbot report:\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460\nModules linked in:\nCPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62\n vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline]\n vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203\n vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256\n vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789\n vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348\n vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline]\n vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118\n __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122\n video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463\n v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl fs/ioctl.c:892 [inline]\n __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2b85c01b19\n...(CVE-2025-22028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: Use kernel helpers for hex dumps\n\nPreviously, when the driver was printing hex dumps, the buffer was cast\nto an 8 byte long and printed using string formatters. If the buffer\nsize was not a multiple of 8 then a read buffer overflow was possible.\n\nTherefore, create a new ibmvnic function that loops over a buffer and\ncalls hex_dump_to_buffer instead.\n\nThis patch address KASAN reports like the one below:\n  ibmvnic 30000003 env3: Login Buffer:\n  ibmvnic 30000003 env3: 01000000af000000\n  \u0026lt;...\u0026gt;\n  ibmvnic 30000003 env3: 2e6d62692e736261\n  ibmvnic 30000003 env3: 65050003006d6f63\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic]\n  Read of size 8 at addr c0000001331a9aa8 by task ip/17681\n  \u0026lt;...\u0026gt;\n  Allocated by task 17681:\n  \u0026lt;...\u0026gt;\n  ibmvnic_login+0x2f0/0xffc [ibmvnic]\n  ibmvnic_open+0x148/0x308 [ibmvnic]\n  __dev_open+0x1ac/0x304\n  \u0026lt;...\u0026gt;\n  The buggy address is located 168 bytes inside of\n                allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf)\n  \u0026lt;...\u0026gt;\n  =================================================================\n  ibmvnic 30000003 env3: 000000000033766e(CVE-2025-22104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nax25: Remove broken autobind\n\nBinding AX25 socket by using the autobind feature leads to memory leaks\nin ax25_connect() and also refcount leaks in ax25_release(). Memory\nleak was detected with kmemleak:\n\n================================================================\nunreferenced object 0xffff8880253cd680 (size 96):\nbacktrace:\n__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)\nkmemdup_noprof (mm/util.c:136)\nax25_rt_autobind (net/ax25/ax25_route.c:428)\nax25_connect (net/ax25/af_ax25.c:1282)\n__sys_connect_file (net/socket.c:2045)\n__sys_connect (net/socket.c:2064)\n__x64_sys_connect (net/socket.c:2067)\ndo_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n================================================================\n\nWhen socket is bound, refcounts must be incremented the way it is done\nin ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case of\nautobind, the refcounts are not incremented.\n\nThis bug leads to the following issue reported by Syzkaller:\n\n================================================================\nax25_connect(): syz-executor318 uses autobind, please contact (CVE-2025-22109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix potential deadloop in prepare_compress_overwrite()\n\nJan Prusakowski reported a kernel hang issue as below:\n\nWhen running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I\nencountered a problem in generic/475 test where fsstress process\ngets blocked in __f2fs_write_data_pages() and the test hangs.\nThe options I used are:\n\nMKFS_OPTIONS  -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc\nMOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc\n\nINFO: task kworker/u8:0:11 blocked for more than 122 seconds.\n      Not tainted 6.14.0-rc3-xfstests-lockdep #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/u8:0    state:D stack:0     pid:11    tgid:11    ppid:2      task_flags:0x4208160 flags:0x00004000\nWorkqueue: writeback wb_workfn (flush-253:0)\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __schedule+0x309/0x8e0\n schedule+0x3a/0x100\n schedule_preempt_disabled+0x15/0x30\n __mutex_lock+0x59a/0xdb0\n __f2fs_write_data_pages+0x3ac/0x400\n do_writepages+0xe8/0x290\n __writeback_single_inode+0x5c/0x360\n writeback_sb_inodes+0x22f/0x570\n wb_writeback+0xb0/0x410\n wb_do_writeback+0x47/0x2f0\n wb_workfn+0x5a/0x1c0\n process_one_work+0x223/0x5b0\n worker_thread+0x1d5/0x3c0\n kthread+0xfd/0x230\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nThe root cause is: once generic/475 starts toload error table to dm\ndevice, f2fs_prepare_compress_overwrite() will loop reading compressed\ncluster pages due to IO error, meanwhile it has held .writepages lock,\nit can block all other writeback tasks.\n\nLet\u0026apos;s fix this issue w/ below changes:\n- add f2fs_handle_page_eio() in prepare_compress_overwrite() to\ndetect IO error.\n- detect cp_error earler in f2fs_read_multi_pages().(CVE-2025-22127)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t type\n\nThe access to the PCI config space via pci_ops::read and pci_ops::write is\na low-level hardware access. The functions can be accessed with disabled\ninterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for this\npurpose.\n\nA spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot be\nacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed in\nthe same context as the pci_lock.\n\nMake vmd_dev::cfg_lock a raw_spinlock_t type so it can be used with\ninterrupts disabled.\n\nThis was reported as:\n\n  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n  Call Trace:\n   rt_spin_lock+0x4e/0x130\n   vmd_pci_read+0x8d/0x100 [vmd]\n   pci_user_read_config_byte+0x6f/0xe0\n   pci_read_config+0xfe/0x290\n   sysfs_kf_bin_read+0x68/0x90\n\n[bigeasy: reword commit message]\nTested-off-by: Luis Claudio R. Goncalves \u0026lt;(CVE-2025-23161)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: ignore xattrs past end\n\nOnce inside \u0026apos;ext4_xattr_inode_dec_ref_all\u0026apos; we should\nignore xattrs entries past the \u0026apos;end\u0026apos; entry.\n\nThis fixes the following KASAN reported issue:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\nRead of size 4 at addr ffff888012c120c4 by task repro/2065\n\nCPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x1fd/0x300\n ? tcp_gro_dev_warn+0x260/0x260\n ? _printk+0xc0/0x100\n ? read_lock_is_recursive+0x10/0x10\n ? irq_work_queue+0x72/0xf0\n ? __virt_addr_valid+0x17b/0x4b0\n print_address_description+0x78/0x390\n print_report+0x107/0x1f0\n ? __virt_addr_valid+0x17b/0x4b0\n ? __virt_addr_valid+0x3ff/0x4b0\n ? __phys_addr+0xb5/0x160\n ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n kasan_report+0xcc/0x100\n ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n ? ext4_xattr_delete_inode+0xd30/0xd30\n ? __ext4_journal_ensure_credits+0x5f0/0x5f0\n ? __ext4_journal_ensure_credits+0x2b/0x5f0\n ? inode_update_timestamps+0x410/0x410\n ext4_xattr_delete_inode+0xb64/0xd30\n ? ext4_truncate+0xb70/0xdc0\n ? ext4_expand_extra_isize_ea+0x1d20/0x1d20\n ? __ext4_mark_inode_dirty+0x670/0x670\n ? ext4_journal_check_start+0x16f/0x240\n ? ext4_inode_is_fast_symlink+0x2f2/0x3a0\n ext4_evict_inode+0xc8c/0xff0\n ? ext4_inode_is_fast_symlink+0x3a0/0x3a0\n ? do_raw_spin_unlock+0x53/0x8a0\n ? ext4_inode_is_fast_symlink+0x3a0/0x3a0\n evict+0x4ac/0x950\n ? proc_nr_inodes+0x310/0x310\n ? trace_ext4_drop_inode+0xa2/0x220\n ? _raw_spin_unlock+0x1a/0x30\n ? iput+0x4cb/0x7e0\n do_unlinkat+0x495/0x7c0\n ? try_break_deleg+0x120/0x120\n ? 0xffffffff81000000\n ? __check_object_size+0x15a/0x210\n ? strncpy_from_user+0x13e/0x250\n ? getname_flags+0x1dc/0x530\n __x64_sys_unlinkat+0xc8/0xf0\n do_syscall_64+0x65/0x110\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x434ffd\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8\nRSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107\nRAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd\nRDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005\nRBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001\n \u0026lt;/TASK\u0026gt;\n\nThe buggy address belongs to the object at ffff888012c12000\n which belongs to the cache filp of size 360\nThe buggy address is located 196 bytes inside of\n freed 360-byte region [ffff888012c12000, ffff888012c12168)\n\nThe buggy address belongs to the physical page:\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12\nhead: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\nflags: 0x40(head|node=0|zone=0)\npage_type: f5(slab)\nraw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004\nraw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000\nhead: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004\nhead: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000\nhead: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000\nhead: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n\u0026gt; ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                           ^\n ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc\n ffff888012c12180: fc fc fc fc fc fc fc fc fc\n---truncated---(CVE-2025-37738)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix hang while freeing sigtrap event\n\nPerf can hang while freeing a sigtrap event if a related deferred\nsignal hadn\u0026apos;t managed to be sent before the file got closed:\n\nperf_event_overflow()\n   task_work_add(perf_pending_task)\n\nfput()\n   task_work_add(____fput())\n\ntask_work_run()\n    ____fput()\n        perf_release()\n            perf_event_release_kernel()\n                _free_event()\n                    perf_pending_task_sync()\n                        task_work_cancel() -\u0026gt; FAILED\n                        rcuwait_wait_event()\n\nOnce task_work_run() is running, the list of pending callbacks is\nremoved from the task_struct and from this point on task_work_cancel()\ncan\u0026apos;t remove any pending and not yet started work items, hence the\ntask_work_cancel() failure and the hang on rcuwait_wait_event().\n\nTask work could be changed to remove one work at a time, so a work\nrunning on the current task can always cancel a pending one, however\nthe wait / wake design is still subject to inverted dependencies when\nremote targets are involved, as pictured by Oleg:\n\nT1                                                      T2\n\nfd = perf_event_open(pid =\u0026gt; T2-\u0026gt;pid);                  fd = perf_event_open(pid =\u0026gt; T1-\u0026gt;pid);\nclose(fd)                                              close(fd)\n    \u0026lt;IRQ\u0026gt;                                                  \u0026lt;IRQ\u0026gt;\n    perf_event_overflow()                                  perf_event_overflow()\n       task_work_add(perf_pending_task)                        task_work_add(perf_pending_task)\n    \u0026lt;/IRQ\u0026gt;                                                 \u0026lt;/IRQ\u0026gt;\n    fput()                                                 fput()\n        task_work_add(____fput())                              task_work_add(____fput())\n\n    task_work_run()                                        task_work_run()\n        ____fput()                                             ____fput()\n            perf_release()                                         perf_release()\n                perf_event_release_kernel()                            perf_event_release_kernel()\n                    _free_event()                                          _free_event()\n                        perf_pending_task_sync()                               perf_pending_task_sync()\n                            rcuwait_wait_event()                                   rcuwait_wait_event()\n\nTherefore the only option left is to acquire the event reference count\nupon queueing the perf task work and release it from the task work, just\nlike it was done before 3a5465418f5f (\u0026quot;perf: Fix event leak upon exec and file release\u0026quot;)\nbut without the leaks it fixed.\n\nSome adjustments are necessary to make it work:\n\n* A child event might dereference its parent upon freeing. Care must be\n  taken to release the parent last.\n\n* Some places assuming the event doesn\u0026apos;t have any reference held and\n  therefore can be freed right away must instead put the reference and\n  let the reference counting to its job.(CVE-2025-37747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix reference leak in pci_register_host_bridge()\n\nIf device_register() fails, call put_device() to give up the reference to\navoid a memory leak, per the comment at device_register().\n\nFound by code review.\n\n[bhelgaas: squash Dan Carpenter\u0026apos;s double free fix from\nhttps://lore.kernel.org/r/(CVE-2025-37836)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix slab-use-after-free in hdcp\n\nThe HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector\nobjects without incrementing the kref reference counts. When using a\nUSB-C dock, and the dock is unplugged, the corresponding\namdgpu_dm_connector objects are freed, creating dangling pointers in the\nHDCP code. When the dock is plugged back, the dangling pointers are\ndereferenced, resulting in a slab-use-after-free:\n\n[   66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu]\n[   66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10\n\n[   66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233\n[   66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024\n[   66.776186] Workqueue: events event_property_validate [amdgpu]\n[   66.776494] Call Trace:\n[   66.776496]  \u0026lt;TASK\u0026gt;\n[   66.776497]  dump_stack_lvl+0x70/0xa0\n[   66.776504]  print_report+0x175/0x555\n[   66.776507]  ? __virt_addr_valid+0x243/0x450\n[   66.776510]  ? kasan_complete_mode_report_info+0x66/0x1c0\n[   66.776515]  kasan_report+0xeb/0x1c0\n[   66.776518]  ? event_property_validate+0x42f/0x6c0 [amdgpu]\n[   66.776819]  ? event_property_validate+0x42f/0x6c0 [amdgpu]\n[   66.777121]  __asan_report_load4_noabort+0x14/0x20\n[   66.777124]  event_property_validate+0x42f/0x6c0 [amdgpu]\n[   66.777342]  ? __lock_acquire+0x6b40/0x6b40\n[   66.777347]  ? enable_assr+0x250/0x250 [amdgpu]\n[   66.777571]  process_one_work+0x86b/0x1510\n[   66.777575]  ? pwq_dec_nr_in_flight+0xcf0/0xcf0\n[   66.777578]  ? assign_work+0x16b/0x280\n[   66.777580]  ? lock_is_held_type+0xa3/0x130\n[   66.777583]  worker_thread+0x5c0/0xfa0\n[   66.777587]  ? process_one_work+0x1510/0x1510\n[   66.777588]  kthread+0x3a2/0x840\n[   66.777591]  ? kthread_is_per_cpu+0xd0/0xd0\n[   66.777594]  ? trace_hardirqs_on+0x4f/0x60\n[   66.777597]  ? _raw_spin_unlock_irq+0x27/0x60\n[   66.777599]  ? calculate_sigpending+0x77/0xa0\n[   66.777602]  ? kthread_is_per_cpu+0xd0/0xd0\n[   66.777605]  ret_from_fork+0x40/0x90\n[   66.777607]  ? kthread_is_per_cpu+0xd0/0xd0\n[   66.777609]  ret_from_fork_asm+0x11/0x20\n[   66.777614]  \u0026lt;/TASK\u0026gt;\n\n[   66.777643] Allocated by task 10:\n[   66.777646]  kasan_save_stack+0x39/0x60\n[   66.777649]  kasan_save_track+0x14/0x40\n[   66.777652]  kasan_save_alloc_info+0x37/0x50\n[   66.777655]  __kasan_kmalloc+0xbb/0xc0\n[   66.777658]  __kmalloc_cache_noprof+0x1c8/0x4b0\n[   66.777661]  dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu]\n[   66.777880]  drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper]\n[   66.777892]  drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper]\n[   66.777901]  drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper]\n[   66.777909]  drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper]\n[   66.777917]  process_one_work+0x86b/0x1510\n[   66.777919]  worker_thread+0x5c0/0xfa0\n[   66.777922]  kthread+0x3a2/0x840\n[   66.777925]  ret_from_fork+0x40/0x90\n[   66.777927]  ret_from_fork_asm+0x11/0x20\n\n[   66.777932] Freed by task 1713:\n[   66.777935]  kasan_save_stack+0x39/0x60\n[   66.777938]  kasan_save_track+0x14/0x40\n[   66.777940]  kasan_save_free_info+0x3b/0x60\n[   66.777944]  __kasan_slab_free+0x52/0x70\n[   66.777946]  kfree+0x13f/0x4b0\n[   66.777949]  dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu]\n[   66.778179]  drm_connector_free+0x7d/0xb0\n[   66.778184]  drm_mode_object_put.part.0+0xee/0x160\n[   66.778188]  drm_mode_object_put+0x37/0x50\n[   66.778191]  drm_atomic_state_default_clear+0x220/0xd60\n[   66.778194]  __drm_atomic_state_free+0x16e/0x2a0\n[   66.778197]  drm_mode_atomic_ioctl+0x15ed/0x2ba0\n[   66.778200]  drm_ioctl_kernel+0x17a/0x310\n[   66.778203]  drm_ioctl+0x584/0xd10\n[   66.778206]  amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu]\n[   66.778375]  __x64_sys_ioctl+0x139/0x1a0\n[   66.778378]  x64_sys_call+0xee7/0xfb0\n[   66.778381] \n---truncated---(CVE-2025-37903)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: Fix UAF in __close_file_table_ids\n\nA use-after-free is possible if one thread destroys the file\nvia __ksmbd_close_fd while another thread holds a reference to\nit. The existing checks on fp-\u0026gt;refcount are not sufficient to\nprevent this.\n\nThe fix takes ft-\u0026gt;lock around the section which removes the\nfile from the file table. This prevents two threads acquiring the\nsame file pointer via __close_file_table_ids, as well as the other\nfunctions which retrieve a file from the IDR and which already use\nthis same lock.(CVE-2025-37952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfix a couple of races in MNT_TREE_BENEATH handling by do_move_mount()\n\nNormally do_lock_mount(path, _) is locking a mountpoint pinned by\n*path and at the time when matching unlock_mount() unlocks that\nlocation it is still pinned by the same thing.\n\nUnfortunately, for \u0026apos;beneath\u0026apos; case it\u0026apos;s no longer that simple -\nthe object being locked is not the one *path points to.  It\u0026apos;s the\nmountpoint of path-\u0026gt;mnt.  The thing is, without sufficient locking\n-\u0026gt;mnt_parent may change under us and none of the locks are held\nat that point.  The rules are\n\t* mount_lock stabilizes m-\u0026gt;mnt_parent for any mount m.\n\t* namespace_sem stabilizes m-\u0026gt;mnt_parent, provided that\nm is mounted.\n\t* if either of the above holds and refcount of m is positive,\nwe are guaranteed the same for refcount of m-\u0026gt;mnt_parent.\n\nnamespace_sem nests inside inode_lock(), so do_lock_mount() has\nto take inode_lock() before grabbing namespace_sem.  It does\nrecheck that path-\u0026gt;mnt is still mounted in the same place after\ngetting namespace_sem, and it does take care to pin the dentry.\nIt is needed, since otherwise we might end up with racing mount --move\n(or umount) happening while we were getting locks; in that case\ndentry would no longer be a mountpoint and could\u0026apos;ve been evicted\non memory pressure along with its inode - not something you want\nwhen grabbing lock on that inode.\n\nHowever, pinning a dentry is not enough - the matching mount is\nalso pinned only by the fact that path-\u0026gt;mnt is mounted on top it\nand at that point we are not holding any locks whatsoever, so\nthe same kind of races could end up with all references to\nthat mount gone just as we are about to enter inode_lock().\nIf that happens, we are left with filesystem being shut down while\nwe are holding a dentry reference on it; results are not pretty.\n\nWhat we need to do is grab both dentry and mount at the same time;\nthat makes inode_lock() safe *and* avoids the problem with fs getting\nshut down under us.  After taking namespace_sem we verify that\npath-\u0026gt;mnt is still mounted (which stabilizes its -\u0026gt;mnt_parent) and\ncheck that it\u0026apos;s still mounted at the same place.  From that point\non to the matching namespace_unlock() we are guaranteed that\nmount/dentry pair we\u0026apos;d grabbed are also pinned by being the mountpoint\nof path-\u0026gt;mnt, so we can quietly drop both the dentry reference (as\nthe current code does) and mnt one - it\u0026apos;s OK to do under namespace_sem,\nsince we are not dropping the final refs.\n\nThat solves the problem on do_lock_mount() side; unlock_mount()\nalso has one, since dentry is guaranteed to stay pinned only until\nthe namespace_unlock().  That\u0026apos;s easy to fix - just have inode_unlock()\ndone earlier, while it\u0026apos;s still pinned by mp-\u0026gt;m_dentry.(CVE-2025-37988)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-95.0.0.99.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","perf-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-95.0.0.99.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-95.0.0.99.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","perf-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-95.0.0.99.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1595"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50140"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53175"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53188"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53200"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56568"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21676"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21919"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22104"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22109"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22127"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23161"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37738"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37747"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37836"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37903"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37952"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37988"}],"database_specific":{"severity":"High"}}