CVE-2026-74692 in Linux
Zusammenfassung
von VulDB • 23.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net/smc: Behebung eines TOCTOU-Race-Conditions zwischen smc_listen_out() und dem Schließen des Listeners
smc_listen_out() liest lsmc->sk.sk_state ohne den Listener-Sperre (Lock), erwirbt dann erst nach Bestehen der Prüfung lock_sock_nested(). Dies öffnet ein Zeitfenster, in dem smc_close_active() den Listener auf SMC_CLOSED setzen kann, smc_close_cleanup_listen() aufruft, um die Accept-Warteschlange zu leeren, und die Sperre freigibt – alles zwischen der sperrlosen Leseoperation und der verzögerten Sperrerwerbung:
smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* Kind-Socket wird auf totem Listener eingereiht */
smc_close_active() leert nur tcp_listen_work. Arbeitsitems, die bereits für den CLC-Handshake an smc_hs_wq übergeben wurden, laufen weiterhin ungeschützt weiter. smc_accept_enqueue() nimmt einen sock_hold() am Kind-Socket vor, der niemals freigegeben wird, sodass der kindliche SMC-Socket (smc_sock), dessen clcsock und die Referenzen alle lecken (Memory Leak). Ein entfernter Peer, der TCP-Verbindungen öffnet, während der Server close() aufruft, kann den Kernel-Speicher erschöpfen.
Verschieben Sie lock_sock_nested() vor die sk_state-Prüfung, damit Test und Einfügen atomar unter der Listener-Sperre erfolgen.
If you want to get best quality of vulnerability data, you may have to visit VulDB.