CVE-2026-72390

CVE CVE-2026-72390EUVD EUVD-2026-59289Veröffentlicht 2026-08-15T05:56:19.000ZZuletzt geändert 2026-08-17T05:43:36.000ZCVSS 7.8

Was das Advisory beschreibt

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF The teql master->slaves singly linked list is not protected against multiple writes. It can be mod'ed concurently from teql_master_xmit(), teql_dequeue(), teql_init() and teql_destroy() without holding any list lock or RCU protection. zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed after an RCU grace period, but teql_master_xmit() running on another CPU can still hold a stale pointer into the list, resulting in a slab-use-after-free: BUG: KASAN: slab-use-after-free in teql_master_xmit+0xf0f/0x16b0 Read of size 8 at addr ffff888013fb0440 by task poc/332 Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512) The fix? Add a per-master slaves_lock spinlock that serializes all mutations of master->slaves and the NEXT_SLAVE() links in teql_destroy() and teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock around those updates. Annotate master->slaves and the per-slave ->next pointer with __rcu and use the appropriate RCU accessors everywhere they are touched: rcu_assign_pointer() on the writer side (under slaves_lock), rcu_dereference_protected() for the writer-side loads (also under slaves_lock), rcu_dereference_bh() for the loads in teql_master_xmit() and rtnl_dereference() for the loads in teql_master_open()/teql_master_mtu(), which run under RTNL. Pair this with rcu_read_lock_bh()/rcu_read_unlock_bh() around the list traversal in teql_master_xmit(), so that readers either observe a fully linked list or are deferred until the in-flight mutation completes. The two early-return paths in teql_master_xmit() are updated to release the RCU-bh read-side critical section before returning, since leaving it held would disable BH on that CPU for good.

Quelle: EUVD (ENISA), im Wortlaut der Meldung.

Produkte, die das Advisory nennt

Diese Angaben stammen aus der Meldung selbst, nicht aus einer Prüfung durch uns.

• Linux — Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <11402e6e18e96df615cbcc58157818dd604b23ff; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <03c67781254c574ae7fa75e881239a78473bdf42; patch: 6.1.178; patch: 7.2; patch: 0; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <9b7d05cbaa60108642402100efa6aa288dd33023; patch: 6.18.40; patch: 6.12.97; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <b26aa9d993537a4c3167d8ceead3b7c69c3a0aac; patch: 7.1.5; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <735567bde7401f82b064f9f107b52ee1bf84ed8c; 2.6.12; 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <e5b811fe793166aecc59b085c1b7c31262ef2316; patch: 6.6.145

Die genannten Versionen sind die Angabe der Meldung. Patchlage vergleicht keine Versionsnummern und leitet aus ihnen keine Aussage ab — welche Version installiert ist, muss ein Mensch nachsehen.

Im Produktkatalog geführt

Für diese Produkte kann ein Bestand in Patchlage erfasst werden. Ein Advisory dazu erscheint am Morgen danach im Lagebericht.

• Linux — Linux

Patchlage meldet Treffer und Verdachtsfälle. Zu allem anderen sagt dieses System nichts — weder diese Seite noch der Lagebericht behauptet je, dass ein Bestand sicher ist.