CVE-2024-44975 in Linux
Summary
by MITRE • 09/04/2024
In the Linux kernel, the following vulnerability has been resolved:
cgroup/cpuset: fix panic caused by partcmd_update
We find a bug as below: BUG: unable to handle page fault for address: 00000003 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 358 Comm: bash Tainted: G W I 6.6.0-10893-g60d6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4 RIP: 0010:partition_sched_domains_locked+0x483/0x600 Code: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9 RSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202 RAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80 RBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000 R10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002 R13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0 Call Trace: ? show_regs+0x8c/0xa0 ? __die_body+0x23/0xa0 ? __die+0x3a/0x50 ? page_fault_oops+0x1d2/0x5c0 ? partition_sched_domains_locked+0x483/0x600 ? search_module_extables+0x2a/0xb0 ? search_exception_tables+0x67/0x90 ? kernelmode_fixup_or_oops+0x144/0x1b0 ? __bad_area_nosemaphore+0x211/0x360 ? up_read+0x3b/0x50 ? bad_area_nosemaphore+0x1a/0x30 ? exc_page_fault+0x890/0xd90 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? __lock_acquire.constprop.0+0x24f/0x8d0 ? asm_exc_page_fault+0x26/0x30 ? partition_sched_domains_locked+0x483/0x600 ? partition_sched_domains_locked+0xf0/0x600 rebuild_sched_domains_locked+0x806/0xdc0 update_partition_sd_lb+0x118/0x130 cpuset_write_resmask+0xffc/0x1420 cgroup_file_write+0xb2/0x290 kernfs_fop_write_iter+0x194/0x290 new_sync_write+0xeb/0x160 vfs_write+0x16f/0x1d0 ksys_write+0x81/0x180 __x64_sys_write+0x21/0x30 x64_sys_call+0x2f25/0x4630 do_syscall_64+0x44/0xb0 entry_SYSCALL_64_after_hwframe+0x78/0xe2 RIP: 0033:0x7f44a553c887
It can be reproduced with cammands: cd /sys/fs/cgroup/ mkdir test cd test/ echo +cpuset > ../cgroup.subtree_control echo root > cpuset.cpus.partition cat /sys/fs/cgroup/cpuset.cpus.effective 0-3 echo 0-3 > cpuset.cpus // taking away all cpus from root
This issue is caused by the incorrect rebuilding of scheduling domains. In this scenario, test/cpuset.cpus.partition should be an invalid root and should not trigger the rebuilding of scheduling domains. When calling update_parent_effective_cpumask with partcmd_update, if newmask is not null, it should recheck newmask whether there are cpus is available for parect/cs that has tasks.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/17/2026
The vulnerability described in CVE-2024-44975 affects the Linux kernel's cgroup and cpuset subsystems, specifically exposing a critical panic condition triggered during partition command updates. This issue manifests as a page fault occurring at address 0x00000003, resulting in a kernel oops and system panic. The bug arises from improper handling of scheduling domain rebuilding when cpuset partition commands are processed, particularly when transitioning from a valid partition state to one that would leave parent cgroup schedulers without available CPUs. The kernel's partition_sched_domains_locked function attempts to rebuild scheduling domains without adequately validating that parent cgroups still possess CPU resources for task scheduling, leading to memory access violations.
The technical flaw stems from a logic error in the cpuset subsystem where update_partition_sd_lb function fails to properly validate CPU mask availability before initiating scheduling domain rebuilds. When the command echo 0-3 > cpuset.cpus is executed, it removes all CPUs from the root cpuset, creating an invalid state where child cgroups attempt to update their scheduling domains without proper CPU allocation. The kernel does not correctly check whether parent cgroups still maintain sufficient CPU resources for task scheduling, causing a dereference of invalid memory addresses during the partition command processing. This condition is classified as a memory management error and corresponds to CWE-125, representing out-of-bounds read conditions that can lead to system crashes.
The operational impact of this vulnerability is significant as it can cause complete system panics and kernel oops conditions, effectively rendering systems unstable and potentially leading to denial of service scenarios. Attackers could exploit this by crafting specific cgroup partition commands that trigger the problematic code path, causing system crashes in environments heavily reliant on cgroup management such as containerized deployments, virtualization platforms, and cloud infrastructure. The vulnerability particularly affects systems using kernel versions that include the problematic cpuset implementation, where cgroup management is extensively used for resource isolation and scheduling control. This vulnerability aligns with ATT&CK technique T1499.001, which involves compromising availability through system resource exhaustion or kernel panic conditions.
Mitigation strategies include applying the kernel patch that addresses the improper scheduling domain rebuilding logic, specifically ensuring that update_parent_effective_cpumask properly validates CPU mask availability before triggering domain rebuilds. Administrators should also implement monitoring for cgroup operations that modify CPU partitioning, as early detection of problematic commands can prevent exploitation. Additionally, system administrators should ensure kernel updates are applied promptly, as this vulnerability affects the core kernel scheduling subsystem and can compromise system stability across multiple deployment scenarios. The fix involves adding proper validation checks to verify that parent cgroups maintain sufficient CPU resources before attempting scheduling domain modifications, preventing the invalid memory access that causes the kernel panic.