In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Prevent dead task groups from regaining cfs_rq's
Kevin is reporting crashes which point to a use-after-free of a cfs_rq in update_blocked_averages(). Initial debugging revealed that we've live cfs_rq's (on_list=1) in an about to be kfree()'d task group in free_fair_sched_group(). However, it was unclear how that can happen.
His kernel config happened to lead to a layout of struct sched_entity that put the 'my_q' member directly into the middle of the object which makes it incidentally overlap with SLUB's freelist pointer. That, in combination with SLAB_FREELIST_HARDENED's freelist pointer mangling, leads to a reliable access violation in form of a #GP which made the UAF fail fast.
Michal seems to have run into the same issue[1]. He already correctly diagnosed that commit a7b359fc6a37 ("sched/fair: Correctly insert cfs_rq's to list on unthrottle") is causing the preconditions for the UAF to happen by re-adding cfs_rq's also to task groups that have no more running tasks, i.e. also to dead ones. His analysis, however, misses the real root cause and it cannot be seen from the crash backtrace only, as the real offender is tg_unthrottle_up() getting called via sched_cfs_period_timer() via the timer interrupt at an inconvenient time.
When unregister_fair_sched_group() unlinks all cfs_rq's from the dying task group, it doesn't protect itself from getting interrupted. If the timer interrupt triggers while we iterate over all CPUs or after unregister_fair_sched_group() has finished but prior to unlinking the task group, sched_cfs_period_timer() will execute and walk the list of task groups, trying to unthrottle cfs_rq's, i.e. re-add them to the dying task group. These will later -- in free_fair_sched_group() -- be kfree()'ed while still being linked, leading to the fireworks Kevin and Michal are seeing.
To fix this race, ensure the dying task group gets unlinked first. However, simply switching the order of unregistering and unlinking the task group isn't sufficient, as concurrent RCU walkers might still see it, as can be seen below:
CPU1: CPU2: : timer IRQ: : do_sched_cfs_period_timer(): : : : distribute_cfs_runtime(): : rcu_read_lock(); : : : unthrottle_cfs_rq(): sched_offline_group(): : : walk_tg_tree_from(…,tg_unthrottle_up,…): list_del_rcu(&tg->list); : (1) : list_for_each_entry_rcu(child, &parent->children, siblings) : : (2) list_del_rcu(&tg->siblings); : : tg_unthrottle_up(): unregister_fair_sched_group(): struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)]; : : list_del_leaf_cfs_rq(tg->cfs_rq[cpu]); : : : : if (!cfs_rq_is_decayed(cfs_rq) || cfs_rq->nr_running) (3) : list_add_leaf_cfs_rq(cfs_rq); : : : : : : : : : ---truncated---
CVSS Details
- CVSS 3.1 Base Score: 7.8
- CVSS 3.1 Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Covered by Rapid7
| Product | Vendor Advisory | Solution File | Added | Published |
|---|---|---|---|---|
| Debian | — | Upgrade linux | Jul 30, 2024 | Apr 10, 2024 |
| Huawei Euleros 2_0_sp9 | — | Upgrade kernel-tools-libsUpgrade kernelUpgrade python3-perfUpgrade kernel-tools | Jul 17, 2024 | Apr 10, 2024 |
| Redhat_linux | — | No solution exists | Jul 9, 2025 | Apr 10, 2024 |
| Suse | — | Upgrade kernel-docs-htmlUpgrade kernel-64kb-optionalUpgrade kselftests-kmp-defaultUpgrade gfs2-kmp-defaultUpgrade kernel-64kb-extraUpgrade kernel-source-vanillaUpgrade dtb-hisiliconUpgrade kernel-rt_debug-livepatch-develUpgrade dlm-kmp-defaultUpgrade kernel-azure-extraUpgrade kernel-azureUpgrade kernel-debug-livepatch-develUpgrade kernel-default-baseUpgrade dlm-kmp-azureUpgrade reiserfs-kmp-rtUpgrade kernel-defaultUpgrade dtb-armUpgrade kernel-debug-develUpgrade kernel-obs-buildUpgrade dtb-appleUpgrade kernel-64kb-develUpgrade dlm-kmp-rtUpgrade cluster-md-kmp-64kbUpgrade kernel-rt_debugUpgrade kernel-rt_debug-vdsoUpgrade kselftests-kmp-rtUpgrade reiserfs-kmp-defaultUpgrade kernel-default-livepatch-develUpgrade kernel-docsUpgrade kernel-rt-extraUpgrade dtb-renesasUpgrade cluster-md-kmp-defaultUpgrade dtb-amdUpgrade kernel-rt-livepatch-develUpgrade kernel-azure-vdsoUpgrade kernel-debug-vdsoUpgrade dtb-sprdUpgrade kernel-kvmsmall-vdsoUpgrade ocfs2-kmp-azureUpgrade dtb-marvellUpgrade dtb-socionextUpgrade dtb-rockchipUpgrade kernel-debugUpgrade dtb-nvidiaUpgrade kernel-syms-rtUpgrade kernel-rt_debug-develUpgrade dtb-apmUpgrade kselftests-kmp-azureUpgrade dtb-allwinnerUpgrade kernel-develUpgrade kernel-devel-azureUpgrade dtb-xilinxUpgrade kernel-rtUpgrade kernel-default-extraUpgrade kernel-default-base-rebuildUpgrade kernel-azure-optionalUpgrade kernel-kvmsmall-livepatch-develUpgrade kernel-zfcpdumpUpgrade kernel-64kb-livepatch-develUpgrade kernel-rt-optionalUpgrade ocfs2-kmp-rtUpgrade dtb-amlogicUpgrade dtb-qcomUpgrade dtb-alteraUpgrade kernel-sourceUpgrade kernel-azure-develUpgrade kernel-kvmsmallUpgrade kselftests-kmp-64kbUpgrade dtb-mediatekUpgrade kernel-default-develUpgrade reiserfs-kmp-64kbUpgrade kernel-syms-azureUpgrade dtb-exynosUpgrade gfs2-kmp-64kbUpgrade kernel-rt-develUpgrade kernel-macrosUpgrade ocfs2-kmp-64kbUpgrade kernel-source-azureUpgrade kernel-default-vdsoUpgrade dtb-broadcomUpgrade kernel-obs-qaUpgrade dtb-freescaleUpgrade gfs2-kmp-azureUpgrade kernel-source-rtUpgrade kernel-rt-vdsoUpgrade gfs2-kmp-rtUpgrade kernel-kvmsmall-develUpgrade reiserfs-kmp-azureUpgrade kernel-default-livepatchUpgrade kernel-default-optionalUpgrade kernel-64kbUpgrade cluster-md-kmp-rtUpgrade kernel-symsUpgrade dlm-kmp-64kbUpgrade cluster-md-kmp-azureUpgrade dtb-amazonUpgrade kernel-azure-livepatch-develUpgrade kernel-rt-livepatchUpgrade dtb-lgUpgrade kernel-devel-rtUpgrade dtb-caviumUpgrade ocfs2-kmp-default | Aug 9, 2024 | Apr 10, 2024 |
Prioritise with Active Threat Intelligence
With curated Threat Intelligence, you can see which vulnerabilities truly put you at risk, prioritize what matters most, and act before attackers do.
Explore Intelligence Hub