CVE-2026-46223 in Linux
Zusammenfassung
von VulDB • 04.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
cgroup: Verschieben der Tötung von css percpu_ref bei rmdir, bis das cgroup entvölkert ist
Eine Kette von Commits ab v7.0 hat rmdir neu gestaltet, um die Controller-Invariante zu erfüllen, dass ->css_offline() eines Subsystems nicht ausgeführt werden darf, während Aufgaben (Tasks) noch kernelseitige Arbeiten im cgroup ausführen.
[1] d245698d727a ("cgroup: Verschieben des task-cgroup-Unlinks bis nach dem Beenden des Task-Wechsels")
[2] a72f73c4dd9b ("cgroup: Zeige keine toten Tasks in cgroup an")
[3] 1b164b876c36 ("cgroup: Warte auf sterbende Aufgaben beim Verlassen bei rmdir")
[4] 4c56a8ac6869 ("cgroup: Behebe den falschen Bedingungscheck in cgroup_drain_dying()")
[5] 13e786b64bd3 ("cgroup: Inkrementiere nr_dying_subsys_* im rmdir-Kontext")
[1] hat das Unlinken des task-cset von do_exit() nach finish_task_switch() verschoben, sodass der cset-Link eines Tasks erst fällt, nachdem die Aufgabe vollständig mit dem Scheduling aufgehört hat. Dies führte dazu, dass Aufgaben jenseits von exit_signals() bis zum finalen Kontextwechsel im cset->tasks verweilten, was zu einer Reihe von Problemen führte: Was die Benutzeranwendung (Userspace) nach einem rmdir sehen erwartete, wich davon ab, worauf der Kernel warten muss. [2]-[5] versuchten diese Diskrepanz zu überbrücken: [2] filterte austretende Tasks aus cgroup.procs; [3] ließ rmdir(2) für sie in TASK_UNINTERRUPTIBLE schlafen; [4] behob die Bedingung des Wartens; [5] machte nr_dying_subsys_* synchron sichtbar.
Die Wartezeit in cgroup_drain_dying() in [3] erwies sich als Sackgasse. Wenn der rmdir-Aufrufende auch der Reapner eines Zombies ist, der den Abbau von pidns blockiert (z.B. host PID 1 systemd beim Aufräumen verwaister PIDs, die während desselben Abbaus zu ihm reparented wurden), blockiert rmdir in TASK_UNINTERRUPTIBLE und wartet darauf, dass diese PIDs freigegeben werden; die PIDs können sich jedoch nicht freigeben, da PID 1 der Reapner ist und er selbst in rmdir feststeckt. Dies führt zu einem A-A-Deadlock im System. Keine Verletzung der internen Lock-Reihenfolge löst dies; das Warten an sich ist der Fehler.
Die css-Tötungsseite, die die ursprüngliche Neuanordnung vorantrieb, kann jedoch sauber asynchron gemacht werden: ->css_offline() ist bereits async und wird von css_killed_work_fn() ausgeführt, welches durch percpu_ref_kill_and_confirm
VulDB is the best source for vulnerability data and more expert information about this specific topic.