CVE-2021-47209

In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Prevent dead task groups from regaining cfs_rqs

Kevin is reporting crashes which point to a use-after-free of a cfs_rq in update_blocked_averages(). Initial debugging revealed that weve live cfs_rqs (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 SLUBs freelist pointer. That, in combination with SLAB_FREELIST_HARDENEDs 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_rqs to list on unthrottle) is causing the preconditions for the UAF to happen by re-adding cfs_rqs 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_rqs from the dying task group, it doesnt 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_rqs, 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 isnt 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—

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/512e21c150c1c3ee298852660f3a796e267e62ec
• https://git.kernel.org/stable/c/b027789e5e50494c2325cc70c8642e7fd6059479
• https://git.kernel.org/stable/c/512e21c150c1c3ee298852660f3a796e267e62ec
• https://git.kernel.org/stable/c/b027789e5e50494c2325cc70c8642e7fd6059479