{"id":"OESA-2025-1249","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: fix warning in sched_setaffinity\n\nCommit 8f9ea86fdf99b added some logic to sched_setaffinity that included\na WARN when a per-task affinity assignment races with a cpuset update.\n\nSpecifically, we can have a race where a cpuset update results in the\ntask affinity no longer being a subset of the cpuset. That's fine; we\nhave a fallback to instead use the cpuset mask. However, we have a WARN\nset up that will trigger if the cpuset mask has no overlap at all with\nthe requested task affinity. This shouldn't be a warning condition; its\ntrivial to create this condition.\n\nReproduced the warning by the following setup:\n\n- $PID inside a cpuset cgroup\n- another thread repeatedly switching the cpuset cpus from 1-2 to just 1\n- another thread repeatedly setting the $PID affinity (via taskset) to 2(CVE-2024-41932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix IPIs usage in kfence_protect_page()\n\nflush_tlb_kernel_range() may use IPIs to flush the TLBs of all the\ncores, which triggers the following warning when the irqs are disabled:\n\n[    3.455330] WARNING: CPU: 1 PID: 0 at kernel/smp.c:815 smp_call_function_many_cond+0x452/0x520\n[    3.456647] Modules linked in:\n[    3.457218] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7-00010-g91d3de7240b8 #1\n[    3.457416] Hardware name: QEMU QEMU Virtual Machine, BIOS\n[    3.457633] epc : smp_call_function_many_cond+0x452/0x520\n[    3.457736]  ra : on_each_cpu_cond_mask+0x1e/0x30\n[    3.457786] epc : ffffffff800b669a ra : ffffffff800b67c2 sp : ff2000000000bb50\n[    3.457824]  gp : ffffffff815212b8 tp : ff6000008014f080 t0 : 000000000000003f\n[    3.457859]  t1 : ffffffff815221e0 t2 : 000000000000000f s0 : ff2000000000bc10\n[    3.457920]  s1 : 0000000000000040 a0 : ffffffff815221e0 a1 : 0000000000000001\n[    3.457953]  a2 : 0000000000010000 a3 : 0000000000000003 a4 : 0000000000000000\n[    3.458006]  a5 : 0000000000000000 a6 : ffffffffffffffff a7 : 0000000000000000\n[    3.458042]  s2 : ffffffff815223be s3 : 00fffffffffff000 s4 : ff600001ffe38fc0\n[    3.458076]  s5 : ff600001ff950d00 s6 : 0000000200000120 s7 : 0000000000000001\n[    3.458109]  s8 : 0000000000000001 s9 : ff60000080841ef0 s10: 0000000000000001\n[    3.458141]  s11: ffffffff81524812 t3 : 0000000000000001 t4 : ff60000080092bc0\n[    3.458172]  t5 : 0000000000000000 t6 : ff200000000236d0\n[    3.458203] status: 0000000200000100 badaddr: ffffffff800b669a cause: 0000000000000003\n[    3.458373] [<ffffffff800b669a>] smp_call_function_many_cond+0x452/0x520\n[    3.458593] [<ffffffff800b67c2>] on_each_cpu_cond_mask+0x1e/0x30\n[    3.458625] [<ffffffff8000e4ca>] __flush_tlb_range+0x118/0x1ca\n[    3.458656] [<ffffffff8000e6b2>] flush_tlb_kernel_range+0x1e/0x26\n[    3.458683] [<ffffffff801ea56a>] kfence_protect+0xc0/0xce\n[    3.458717] [<ffffffff801e9456>] kfence_guarded_free+0xc6/0x1c0\n[    3.458742] [<ffffffff801e9d6c>] __kfence_free+0x62/0xc6\n[    3.458764] [<ffffffff801c57d8>] kfree+0x106/0x32c\n[    3.458786] [<ffffffff80588cf2>] detach_buf_split+0x188/0x1a8\n[    3.458816] [<ffffffff8058708c>] virtqueue_get_buf_ctx+0xb6/0x1f6\n[    3.458839] [<ffffffff805871da>] virtqueue_get_buf+0xe/0x16\n[    3.458880] [<ffffffff80613d6a>] virtblk_done+0x5c/0xe2\n[    3.458908] [<ffffffff8058766e>] vring_interrupt+0x6a/0x74\n[    3.458930] [<ffffffff800747d8>] __handle_irq_event_percpu+0x7c/0xe2\n[    3.458956] [<ffffffff800748f0>] handle_irq_event+0x3c/0x86\n[    3.458978] [<ffffffff800786cc>] handle_simple_irq+0x9e/0xbe\n[    3.459004] [<ffffffff80073934>] generic_handle_domain_irq+0x1c/0x2a\n[    3.459027] [<ffffffff804bf87c>] imsic_handle_irq+0xba/0x120\n[    3.459056] [<ffffffff80073934>] generic_handle_domain_irq+0x1c/0x2a\n[    3.459080] [<ffffffff804bdb76>] riscv_intc_aia_irq+0x24/0x34\n[    3.459103] [<ffffffff809d0452>] handle_riscv_irq+0x2e/0x4c\n[    3.459133] [<ffffffff809d923e>] call_on_irq_stack+0x32/0x40\n\nSo only flush the local TLB and let the lazy kfence page fault handling\ndeal with the faults which could happen when a core has an old protected\npte version cached in its TLB. That leads to potential inaccuracies which\ncan be tolerated when using kfence.(CVE-2024-53687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nDrivers: hv: util: Avoid accessing a ringbuffer not initialized yet\n\nIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is\nfully initialized, we can hit the panic below:\n\nhv_utils: Registering HyperV Utility Driver\nhv_vmbus: registering driver hv_utils\n...\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1\nRIP: 0010:hv_pkt_iter_first+0x12/0xd0\nCall Trace:\n...\n vmbus_recvpacket\n hv_kvp_onchannelcallback\n vmbus_on_event\n tasklet_action_common\n tasklet_action\n handle_softirqs\n irq_exit_rcu\n sysvec_hyperv_stimer0\n </IRQ>\n <TASK>\n asm_sysvec_hyperv_stimer0\n...\n kvp_register_done\n hvt_op_read\n vfs_read\n ksys_read\n __x64_sys_read\n\nThis can happen because the KVP/VSS channel callback can be invoked\neven before the channel is fully opened:\n1) as soon as hv_kvp_init() -> hvutil_transport_init() creates\n/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and\nregister itself to the driver by writing a message KVP_OP_REGISTER1 to the\nfile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and\nreading the file for the driver's response, which is handled by\nhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().\n\n2) the problem with kvp_register_done() is that it can cause the\nchannel callback to be called even before the channel is fully opened,\nand when the channel callback is starting to run, util_probe()->\nvmbus_open() may have not initialized the ringbuffer yet, so the\ncallback can hit the panic of NULL pointer dereference.\n\nTo reproduce the panic consistently, we can add a "ssleep(10)" for KVP in\n__vmbus_open(), just before the first hv_ringbuffer_init(), and then we\nunload and reload the driver hv_utils, and run the daemon manually within\nthe 10 seconds.\n\nFix the panic by reordering the steps in util_probe() so the char dev\nentry used by the KVP or VSS daemon is not created until after\nvmbus_open() has completed. This reordering prevents the race condition\nfrom happening.(CVE-2024-55916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: control: Avoid WARN() for symlink errors\n\nUsing WARN() for showing the error of symlink creations don't give\nmore information than telling that something goes wrong, since the\nusual code path is a lregister callback from each control element\ncreation.  More badly, the use of WARN() rather confuses fuzzer as if\nit were serious issues.\n\nThis patch downgrades the warning messages to use the normal dev_err()\ninstead of WARN().  For making it clearer, add the function name to\nthe prefix, too.(CVE-2024-56657)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetdevsim: prevent bad user input in nsim_dev_health_break_write()\n\nIf either a zero count or a large one is provided, kernel can crash.(CVE-2024-56716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: fix TSO DMA API usage causing oops\n\nCommit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap\nfor non-paged SKB data") moved the assignment of tx_skbuff_dma[]'s\nmembers to be later in stmmac_tso_xmit().\n\nThe buf (dma cookie) and len stored in this structure are passed to\ndma_unmap_single() by stmmac_tx_clean(). The DMA API requires that\nthe dma cookie passed to dma_unmap_single() is the same as the value\nreturned from dma_map_single(). However, by moving the assignment\nlater, this is not the case when priv->dma_cap.addr64 > 32 as "des"\nis offset by proto_hdr_len.\n\nThis causes problems such as:\n\n  dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed\n\nand with DMA_API_DEBUG enabled:\n\n  DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]\n\nFix this by maintaining "des" as the original DMA cookie, and use\ntso_des to pass the offset DMA cookie to stmmac_tso_allocator().\n\nFull details of the crashes can be found at:\nhttps://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/\nhttps://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/(CVE-2024-56719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/vas: Add close() callback in vas_vm_ops struct\n\nThe mapping VMA address is saved in VAS window struct when the\npaste address is mapped. This VMA address is used during migration\nto unmap the paste address if the window is active. The paste\naddress mapping will be removed when the window is closed or with\nthe munmap(). But the VMA address in the VAS window is not updated\nwith munmap() which is causing invalid access during migration.\n\nThe KASAN report shows:\n[16386.254991] BUG: KASAN: slab-use-after-free in reconfig_close_windows+0x1a0/0x4e8\n[16386.255043] Read of size 8 at addr c00000014a819670 by task drmgr/696928\n\n[16386.255096] CPU: 29 UID: 0 PID: 696928 Comm: drmgr Kdump: loaded Tainted: G    B              6.11.0-rc5-nxgzip #2\n[16386.255128] Tainted: [B]=BAD_PAGE\n[16386.255148] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.00 (NH1110_016) hv:phyp pSeries\n[16386.255181] Call Trace:\n[16386.255202] [c00000016b297660] [c0000000018ad0ac] dump_stack_lvl+0x84/0xe8 (unreliable)\n[16386.255246] [c00000016b297690] [c0000000006e8a90] print_report+0x19c/0x764\n[16386.255285] [c00000016b297760] [c0000000006e9490] kasan_report+0x128/0x1f8\n[16386.255309] [c00000016b297880] [c0000000006eb5c8] __asan_load8+0xac/0xe0\n[16386.255326] [c00000016b2978a0] [c00000000013f898] reconfig_close_windows+0x1a0/0x4e8\n[16386.255343] [c00000016b297990] [c000000000140e58] vas_migration_handler+0x3a4/0x3fc\n[16386.255368] [c00000016b297a90] [c000000000128848] pseries_migrate_partition+0x4c/0x4c4\n...\n\n[16386.256136] Allocated by task 696554 on cpu 31 at 16377.277618s:\n[16386.256149]  kasan_save_stack+0x34/0x68\n[16386.256163]  kasan_save_track+0x34/0x80\n[16386.256175]  kasan_save_alloc_info+0x58/0x74\n[16386.256196]  __kasan_slab_alloc+0xb8/0xdc\n[16386.256209]  kmem_cache_alloc_noprof+0x200/0x3d0\n[16386.256225]  vm_area_alloc+0x44/0x150\n[16386.256245]  mmap_region+0x214/0x10c4\n[16386.256265]  do_mmap+0x5fc/0x750\n[16386.256277]  vm_mmap_pgoff+0x14c/0x24c\n[16386.256292]  ksys_mmap_pgoff+0x20c/0x348\n[16386.256303]  sys_mmap+0xd0/0x160\n...\n\n[16386.256350] Freed by task 0 on cpu 31 at 16386.204848s:\n[16386.256363]  kasan_save_stack+0x34/0x68\n[16386.256374]  kasan_save_track+0x34/0x80\n[16386.256384]  kasan_save_free_info+0x64/0x10c\n[16386.256396]  __kasan_slab_free+0x120/0x204\n[16386.256415]  kmem_cache_free+0x128/0x450\n[16386.256428]  vm_area_free_rcu_cb+0xa8/0xd8\n[16386.256441]  rcu_do_batch+0x2c8/0xcf0\n[16386.256458]  rcu_core+0x378/0x3c4\n[16386.256473]  handle_softirqs+0x20c/0x60c\n[16386.256495]  do_softirq_own_stack+0x6c/0x88\n[16386.256509]  do_softirq_own_stack+0x58/0x88\n[16386.256521]  __irq_exit_rcu+0x1a4/0x20c\n[16386.256533]  irq_exit+0x20/0x38\n[16386.256544]  interrupt_async_exit_prepare.constprop.0+0x18/0x2c\n...\n\n[16386.256717] Last potentially related work creation:\n[16386.256729]  kasan_save_stack+0x34/0x68\n[16386.256741]  __kasan_record_aux_stack+0xcc/0x12c\n[16386.256753]  __call_rcu_common.constprop.0+0x94/0xd04\n[16386.256766]  vm_area_free+0x28/0x3c\n[16386.256778]  remove_vma+0xf4/0x114\n[16386.256797]  do_vmi_align_munmap.constprop.0+0x684/0x870\n[16386.256811]  __vm_munmap+0xe0/0x1f8\n[16386.256821]  sys_munmap+0x54/0x6c\n[16386.256830]  system_call_exception+0x1a0/0x4a0\n[16386.256841]  system_call_vectored_common+0x15c/0x2ec\n\n[16386.256868] The buggy address belongs to the object at c00000014a819670\n                which belongs to the cache vm_area_struct of size 168\n[16386.256887] The buggy address is located 0 bytes inside of\n                freed 168-byte region [c00000014a819670, c00000014a819718)\n\n[16386.256915] The buggy address belongs to the physical page:\n[16386.256928] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a81\n[16386.256950] memcg:c0000000ba430001\n[16386.256961] anon flags: 0x43ffff800000000(node=4|zone=0|lastcpupid=0x7ffff)\n[16386.256975] page_type: 0xfdffffff(slab)\n[16386\n---truncated---(CVE-2024-56765)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: netem: account for backlog updates from child qdisc\n\nIn general, 'qlen' of any classful qdisc should keep track of the\nnumber of packets that the qdisc itself and all of its children holds.\nIn case of netem, 'qlen' only accounts for the packets in its internal\ntfifo. When netem is used with a child qdisc, the child qdisc can use\n'qdisc_tree_reduce_backlog' to inform its parent, netem, about created\nor dropped SKBs. This function updates 'qlen' and the backlog statistics\nof netem, but netem does not account for changes made by a child qdisc.\n'qlen' then indicates the wrong number of packets in the tfifo.\nIf a child qdisc creates new SKBs during enqueue and informs its parent\nabout this, netem's 'qlen' value is increased. When netem dequeues the\nnewly created SKBs from the child, the 'qlen' in netem is not updated.\nIf 'qlen' reaches the configured sch->limit, the enqueue function stops\nworking, even though the tfifo is not full.\n\nReproduce the bug:\nEnsure that the sender machine has GSO enabled. Configure netem as root\nqdisc and tbf as its child on the outgoing interface of the machine\nas follows:\n$ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100\n$ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms\n\nSend bulk TCP traffic out via this interface, e.g., by running an iPerf3\nclient on the machine. Check the qdisc statistics:\n$ tc -s qdisc show dev <oif>\n\nStatistics after 10s of iPerf3 TCP test before the fix (note that\nnetem's backlog > limit, netem stopped accepting packets):\nqdisc netem 1: root refcnt 2 limit 1000 delay 100ms\n Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0)\n backlog 4294528236b 1155p requeues 0\nqdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms\n Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0)\n backlog 0b 0p requeues 0\n\nStatistics after the fix:\nqdisc netem 1: root refcnt 2 limit 1000 delay 100ms\n Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0)\n backlog 0b 0p requeues 0\nqdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms\n Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0)\n backlog 0b 0p requeues 0\n\ntbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'.\nThe interface fully stops transferring packets and "locks". In this case,\nthe child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at\nits limit and no more packets are accepted.\n\nThis patch adds a counter for the entries in the tfifo. Netem's 'qlen' is\nonly decreased when a packet is returned by its dequeue function, and not\nduring enqueuing into the child qdisc. External updates to 'qlen' are thus\naccounted for and only the behavior of the backlog statistics changes. As\nin other qdiscs, 'qlen' then keeps track of  how many packets are held in\nnetem and all of its children. As before, sch->limit remains as the\nmaximum number of packets in the tfifo. The same applies to netem's\nbacklog statistics.(CVE-2024-56770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req()\n\nWhile receiving an MST up request message from one thread in\ndrm_dp_mst_handle_up_req(), the MST topology could be removed from\nanother thread via drm_dp_mst_topology_mgr_set_mst(false), freeing\nmst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL.\nThis could lead to a NULL deref/use-after-free of mst_primary in\ndrm_dp_mst_handle_up_req().\n\nAvoid the above by holding a reference for mst_primary in\ndrm_dp_mst_handle_up_req() while it's used.\n\nv2: Fix kfreeing the request if getting an mst_primary reference fails.(CVE-2024-57798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe 'data' local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix accessing invalid dip_ctx during destroying QP\n\nIf it fails to modify QP to RTR, dip_ctx will not be attached. And\nduring detroying QP, the invalid dip_ctx pointer will be accessed.(CVE-2024-57935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: fix soft lockup in the OOM process\n\nA soft lockup issue was found in the product with about 56,000 tasks were\nin the OOM cgroup, it was traversing them when the soft lockup was\ntriggered.\n\nwatchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]\nCPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G\nHardware name: Huawei Cloud OpenStack Nova, BIOS\nRIP: 0010:console_unlock+0x343/0x540\nRSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13\nRAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247\nRBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040\nR10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0\nR13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n vprintk_emit+0x193/0x280\n printk+0x52/0x6e\n dump_task+0x114/0x130\n mem_cgroup_scan_tasks+0x76/0x100\n dump_header+0x1fe/0x210\n oom_kill_process+0xd1/0x100\n out_of_memory+0x125/0x570\n mem_cgroup_out_of_memory+0xb5/0xd0\n try_charge+0x720/0x770\n mem_cgroup_try_charge+0x86/0x180\n mem_cgroup_try_charge_delay+0x1c/0x40\n do_anonymous_page+0xb5/0x390\n handle_mm_fault+0xc4/0x1f0\n\nThis is because thousands of processes are in the OOM cgroup, it takes a\nlong time to traverse all of them.  As a result, this lead to soft lockup\nin the OOM process.\n\nTo fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks'\nfunction per 1000 iterations.  For global OOM, call\n'touch_softlockup_watchdog' per 1000 iterations to avoid this issue.(CVE-2024-57977)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_flat: Fix integer overflow bug on 32 bit systems\n\nMost of these sizes and counts are capped at 256MB so the math doesn't\nresult in an integer overflow.  The "relocs" count needs to be checked\nas well.  Otherwise on 32bit systems the calculation of "full_data"\ncould be wrong.\n\n\tfull_data = data_len + relocs * sizeof(unsigned long);(CVE-2024-58010)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: remove kernfs active break\n\nA warning was found:\n\nWARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828\nCPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G\nRIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0\nRSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202\nRAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000\nRDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04\nRBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180\nR10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08\nR13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0\nFS:  00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n kernfs_drain+0x15e/0x2f0\n __kernfs_remove+0x165/0x300\n kernfs_remove_by_name_ns+0x7b/0xc0\n cgroup_rm_file+0x154/0x1c0\n cgroup_addrm_files+0x1c2/0x1f0\n css_clear_dir+0x77/0x110\n kill_css+0x4c/0x1b0\n cgroup_destroy_locked+0x194/0x380\n cgroup_rmdir+0x2a/0x140\n\nIt can be explained by:\nrmdir \t\t\t\techo 1 > cpuset.cpus\n\t\t\t\tkernfs_fop_write_iter // active=0\ncgroup_rm_file\nkernfs_remove_by_name_ns\tkernfs_get_active // active=1\n__kernfs_remove\t\t\t\t\t  // active=0x80000002\nkernfs_drain\t\t\tcpuset_write_resmask\nwait_event\n//waiting (active == 0x80000001)\n\t\t\t\tkernfs_break_active_protection\n\t\t\t\t// active = 0x80000001\n// continue\n\t\t\t\tkernfs_unbreak_active_protection\n\t\t\t\t// active = 0x80000002\n...\nkernfs_should_drain_open_files\n// warning occurs\n\t\t\t\tkernfs_put_active\n\nThis warning is caused by 'kernfs_break_active_protection' when it is\nwriting to cpuset.cpus, and the cgroup is removed concurrently.\n\nThe commit 3a5a6d0c2b03 ("cpuset: don't nest cgroup_mutex inside\nget_online_cpus()") made cpuset_hotplug_workfn asynchronous, This change\ninvolves calling flush_work(), which can create a multiple processes\ncircular locking dependency that involve cgroup_mutex, potentially leading\nto a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break\nkernfs active protection in cpuset_write_resmask()") added\n'kernfs_break_active_protection' in the cpuset_write_resmask. This could\nlead to this warning.\n\nAfter the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug\nprocessing synchronous"), the cpuset_write_resmask no longer needs to\nwait the hotplug to finish, which means that concurrent hotplug and cpuset\noperations are no longer possible. Therefore, the deadlock doesn't exist\nanymore and it does not have to 'break active protection' now. To fix this\nwarning, just remove kernfs_break_active_protection operation in the\n'cpuset_write_resmask'.(CVE-2025-21634)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: don't auto enable misc vector\n\nCurrently, there is a time window between misc irq enabled\nand service task inited. If an interrupte is reported at\nthis time, it will cause warning like below:\n\n[   16.324639] Call trace:\n[   16.324641]  __queue_delayed_work+0xb8/0xe0\n[   16.324643]  mod_delayed_work_on+0x78/0xd0\n[   16.324655]  hclge_errhand_task_schedule+0x58/0x90 [hclge]\n[   16.324662]  hclge_misc_irq_handle+0x168/0x240 [hclge]\n[   16.324666]  __handle_irq_event_percpu+0x64/0x1e0\n[   16.324667]  handle_irq_event+0x80/0x170\n[   16.324670]  handle_fasteoi_edge_irq+0x110/0x2bc\n[   16.324671]  __handle_domain_irq+0x84/0xfc\n[   16.324673]  gic_handle_irq+0x88/0x2c0\n[   16.324674]  el1_irq+0xb8/0x140\n[   16.324677]  arch_cpu_idle+0x18/0x40\n[   16.324679]  default_idle_call+0x5c/0x1bc\n[   16.324682]  cpuidle_idle_call+0x18c/0x1c4\n[   16.324684]  do_idle+0x174/0x17c\n[   16.324685]  cpu_startup_entry+0x30/0x6c\n[   16.324687]  secondary_start_kernel+0x1a4/0x280\n[   16.324688] ---[ end trace 6aa0bff672a964aa ]---\n\nSo don't auto enable misc vector when request irq..(CVE-2025-21651)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: don't allow reconnect after disconnect\n\nFollowing process can cause nbd_config UAF:\n\n1) grab nbd_config temporarily;\n\n2) nbd_genl_disconnect() flush all recv_work() and release the\ninitial reference:\n\n  nbd_genl_disconnect\n   nbd_disconnect_and_put\n    nbd_disconnect\n     flush_workqueue(nbd->recv_workq)\n    if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))\n     nbd_config_put\n     -> due to step 1), reference is still not zero\n\n3) nbd_genl_reconfigure() queue recv_work() again;\n\n  nbd_genl_reconfigure\n   config = nbd_get_config_unlocked(nbd)\n   if (!config)\n   -> succeed\n   if (!test_bit(NBD_RT_BOUND, ...))\n   -> succeed\n   nbd_reconnect_socket\n    queue_work(nbd->recv_workq, &args->work)\n\n4) step 1) release the reference;\n\n5) Finially, recv_work() will trigger UAF:\n\n  recv_work\n   nbd_config_put(nbd)\n   -> nbd_config is freed\n   atomic_dec(&config->recv_threads)\n   -> UAF\n\nFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so\nthat nbd_genl_reconfigure() will fail.(CVE-2025-21731)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing/osnoise: Fix resetting of tracepoints\n\nIf a timerlat tracer is started with the osnoise option OSNOISE_WORKLOAD\ndisabled, but then that option is enabled and timerlat is removed, the\ntracepoints that were enabled on timerlat registration do not get\ndisabled. If the option is disabled again and timelat is started, then it\ntriggers a warning in the tracepoint code due to registering the\ntracepoint again without ever disabling it.\n\nDo not use the same user space defined options to know to disable the\ntracepoints when timerlat is removed. Instead, set a global flag when it\nis enabled and use that flag to know to disable the events.\n\n ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options\n ~# echo timerlat > /sys/kernel/tracing/current_tracer\n ~# echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options\n ~# echo nop > /sys/kernel/tracing/current_tracer\n ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options\n ~# echo timerlat > /sys/kernel/tracing/current_tracer\n\nTriggers:\n\n ------------[ cut here ]------------\n WARNING: CPU: 6 PID: 1337 at kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0\n Modules linked in:\n CPU: 6 UID: 0 PID: 1337 Comm: rtla Not tainted 6.13.0-rc4-test-00018-ga867c441128e-dirty #73\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:tracepoint_add_func+0x3b6/0x3f0\n Code: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff <0f> 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b\n RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202\n RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410\n RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002\n R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001\n R13: ffffb9b003a87ce0 R14: ffffffffffffffef R15: 0000000000000008\n FS:  00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0\n Call Trace:\n  <TASK>\n  ? __warn.cold+0xb7/0x14d\n  ? tracepoint_add_func+0x3b6/0x3f0\n  ? report_bug+0xea/0x170\n  ? handle_bug+0x58/0x90\n  ? exc_invalid_op+0x17/0x70\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? __pfx_trace_sched_migrate_callback+0x10/0x10\n  ? tracepoint_add_func+0x3b6/0x3f0\n  ? __pfx_trace_sched_migrate_callback+0x10/0x10\n  ? __pfx_trace_sched_migrate_callback+0x10/0x10\n  tracepoint_probe_register+0x78/0xb0\n  ? __pfx_trace_sched_migrate_callback+0x10/0x10\n  osnoise_workload_start+0x2b5/0x370\n  timerlat_tracer_init+0x76/0x1b0\n  tracing_set_tracer+0x244/0x400\n  tracing_set_trace_write+0xa0/0xe0\n  vfs_write+0xfc/0x570\n  ? do_sys_openat2+0x9c/0xe0\n  ksys_write+0x72/0xf0\n  do_syscall_64+0x79/0x1c0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21733)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix oops when unload drivers paralleling\n\nWhen unload hclge driver, it tries to disable sriov first for each\nae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at\nthe time, because it removes all the ae_dev nodes, and it may cause\noops.\n\nBut we can't simply use hnae3_common_lock for this. Because in the\nprocess flow of pci_disable_sriov(), it will trigger the remove flow\nof VF, which will also take hnae3_common_lock.\n\nTo fixes it, introduce a new mutex to protect the unload process.(CVE-2025-21802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/compaction: fix UBSAN shift-out-of-bounds warning\n\nsyzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order)\nin isolate_freepages_block().  The bogus compound_order can be any value\nbecause it is union with flags.  Add back the MAX_PAGE_ORDER check to fix\nthe warning.(CVE-2025-21815)","modified":"2025-09-03T06:20:26.375902Z","published":"2025-03-07T15:27:39Z","upstream":["CVE-2024-41932","CVE-2024-53687","CVE-2024-55916","CVE-2024-56657","CVE-2024-56716","CVE-2024-56719","CVE-2024-56765","CVE-2024-56770","CVE-2024-57798","CVE-2024-57907","CVE-2024-57935","CVE-2024-57977","CVE-2024-58010","CVE-2025-21634","CVE-2025-21651","CVE-2025-21731","CVE-2025-21733","CVE-2025-21802","CVE-2025-21815"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1249"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41932"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53687"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-55916"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56657"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56716"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56719"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56765"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56770"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57798"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57907"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57935"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57977"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58010"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21634"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21651"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21731"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21733"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21802"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21815"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP1","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-80.0.0.85.oe2403sp1"}]}],"ecosystem_specific":{"src":["kernel-6.6.0-80.0.0.85.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","perf-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-80.0.0.85.oe2403sp1.x86_64.rpm"],"aarch64":["bpftool-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","perf-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-80.0.0.85.oe2403sp1.aarch64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-1249.json"}}],"schema_version":"1.7.3"}