CVE-2021-47209
published 2024-04-10CVE-2021-47209: 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…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.21%
10.8th percentile
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 switc
Affected
8 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.15.5-1 (bookworm) | linux 5.15.5-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= a7b359fc6a37faaf472125867c8dc5a068c90982 < 512e21c150c1c3ee298852660f3a796e267e62ec | 512e21c150c1c3ee298852660f3a796e267e62ec |
| linux | linux | >= a7b359fc6a37faaf472125867c8dc5a068c90982 < b027789e5e50494c2325cc70c8642e7fd6059479 | b027789e5e50494c2325cc70c8642e7fd6059479 |
| linux | linux_kernel | >= 0 < 5.15.5-1 | 5.15.5-1 |
| linux | linux_kernel | >= 0 < 5.15.5-1 | 5.15.5-1 |
| linux | linux_kernel | >= 0 < 5.15.5-1 | 5.15.5-1 |
| linux | linux_kernel | >= 5.13 < 5.15.5 | 5.15.5 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-m59q-rgx4-6vq4: In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Prevent dead task groups from regaining cfs_rq's
Kevin is reporting
ghsa_unreviewed·2024-04-10
CVE-2021-47209 [MEDIUM] CWE-416 GHSA-m59q-rgx4-6vq4: In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Prevent dead task groups from regaining cfs_rq's
Kevin is reporting
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 i
OSV
CVE-2021-47209: In the Linux kernel, the following vulnerability has been resolved: sched/fair: Prevent dead task groups from regaining cfs_rq's Kevin is reporting cr
osv·2024-04-10·CVSS 5.5
CVE-2021-47209 [MEDIUM] CVE-2021-47209: In the Linux kernel, the following vulnerability has been resolved: sched/fair: Prevent dead task groups from regaining cfs_rq's Kevin is reporting cr
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
Red Hat
kernel: sched/fair: Prevent dead task groups from regaining cfs_rq's
vendor_redhat·2024-04-10·CVSS 5.5
CVE-2021-47209 [MEDIUM] CWE-416 kernel: sched/fair: Prevent dead task groups from regaining cfs_rq's
kernel: sched/fair: Prevent dead task groups from regaining cfs_rq's
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
Debian
CVE-2021-47209: linux - In the Linux kernel, the following vulnerability has been resolved: sched/fair:...
vendor_debian·2021·CVSS 5.5
CVE-2021-47209 [MEDIUM] CVE-2021-47209: linux - In the Linux kernel, the following vulnerability has been resolved: sched/fair:...
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
No detection rules found.
No public exploits indexed.
2024-04-10
Published