CVE-2026-74700 in Linux
Zusammenfassung
von VulDB • 23.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net/sched: cls_api: rtnl_lock immer dann erwerben, wenn gesperrte Classifier zerstört werden
Ein weiteres Problem betrifft ungesperrte Filter. Es gibt ein kurzes Zeitfenster in tc_new_tfilter, in dem eine tcf_proto von einer völlig unabhängigen Anfrage eines ungesperrten Classifiers gefunden und kurz referenziert wird, was zu einem Race Condition führen kann.
Feng erstellte einen Proof of Concept (PoC), der diese Race Condition mit zwei Threads erzeugte: ein Thread erstellt einen u32-Filter und der andere einen flower-Filter in derselben Chain/Prio:
1. Beide Threads betreten tc_new_tfilter, stellen beide fest, dass die Chain leer ist, und lassen beide den filter_chain_lock fallen. 2. u32 beendet tcf_proto_create("u32") zuerst, ruft tcf_chain_tp_insert_unique() auf -> fügt u32_tp in die Chain ein. 3. flower beendet tcf_proto_create("flower") später, ruft tcf_chain_tp_insert_unique() auf -> tcf_chain_tp_find() sieht nun bereits u32_tp dort und nimmt eine Referenz darauf an, zerstört das eigene tp_new von flower und gibt u32_tp an den Aufrufer zurück.
Flower trifft dann auf die Kind-Mismatch-Prüfung (da es nach dem "flower"-Kind fragte, aber tp->ops->kind ist "u32") und geht durch den errout-Pfad, der tcf_proto_put() für u32_tp aufruft. Wenn der u32-Thread bereits seinen eigenen errout-Pfad durchlaufen hat (sein change()-Auftschlug beim PoC an den leeren Optionen) und seine Erstellungs- und Einfügereferenzen freigegeben hat, ist die put-Aktion von flower die letzte und senkt den refcnt von u32_tp auf null.
An diesem Punkt wird tp->ops->destroy() in einem Kontext ausgeführt, der niemals rtnl_lock erworben hat. Wenn dies geschieht, kann es zu einer Use-After-Free (UAF) kommen, wie im Folgenden dargestellt (illustriert durch den PoC):
[ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393)
[ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524
Call Trace: u32_init (net/sched/cls_u32.c:393) tc_new_tfilter (net/sched/cls_api.c:2378)
Allocated by task 526: u32_init (net/sched/cls_u32.c:378) tc_new_tfilter (net/sched/cls_api.c:2378)
Freed by task 522: kfree u32_destroy (net/sched/cls_u32.c:662) tcf_proto_destroy (net/sched/cls_api.c:446) tcf_proto_put (net/sched/cls_api.c:459) tc_new_tfilter (net/sched/cls_api.c:2459)
Beheben Sie dies, indem Sie dafür sorgen, dass tcf_proto_destroy() rtnl_lock um tp->ops->destroy() herum erwirbt für gesperrte Classifier, wann immer rtnl nicht gehalten wird.
Um zu erklären, warum ich eine temporäre Variable "not_lockless" verwendet habe, möchte ich auf einen halbwegs verwandten Hinweis hinweisen bezüglich rtnl_held vs. TCF_PROTO_OPS_DOIT_UNLOCKED (hier hinzugefügt für zukünftige Bereinigungen, falls dies als notwendig erachtet wird): Der Parameter rtnl_held und das Flag TCF_PROTO_OPS_DOIT_UNLOCKED sind redundante Quellen der Wahrheit dafür, ob rtnl_lock gehalten wird. Von den neun Destroy-Callbacks von Classifiern (..rtnl_held..) konsultiert nur flower den Parameter rtnl_held, den es an tc_setup_cb_destroy() und tc_setup_cb_call() weiterleitet. Die anderen acht (u32, flow, bpf, cgroup, route, basic, fw, mall) ignorieren ihn vollständig; -> diejenigen, die tc_setup_cb_destroy() aufrufen (u32, bpf, mall), hardcoden immer true anstelle des Parameters weiterzuleiten.
Eine zukünftige Bereinigung sollte den Parameter rtnl_held aus der Signatur des Destroy-Callbacks entfernen und Aufrufer darauf vertrauen lassen, ausschließlich auf ihr eigenes Wissen darüber zu basieren, ob sie in einem ungesperrten Kontext laufen.
If you want to get best quality of vulnerability data, you may have to visit VulDB.