CVE-2026-74560 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
xsk: Behebung eines Buffer-Leaks in xsk_drop_skb() für AF_XDP Multi-Buffer-TX (Transmit)
Dieser Patch ist inspiriert von der Überprüfung [1] durch sashiko. Diese besagt, dass bei einem Überlauf die Adresse des cq (Completion Queue), das veröffentlicht werden soll, ungültig ist. Tatsächlich ist das schwerwiegendere Problem, dass der gesamte Prozess zur Veröffentlichung der cq-Adresse in diesem speziellen Fall nicht korrekt abläuft: Es sollte tatsächlich die Adresse veröffentlichen und den zwischengespeicherten Wert cached_prod im cq erhöhen, solange es Deskriptoren von txq liest.
Im Folgenden finden Sie die vollständige Analyse. xsk_drop_skb() wird an drei Stellen aufgerufen, bei denen ein teilweise aufgebauter Multi-Buffer-SKB (Socket Kernel Buffer) verworfen wird: 1) xsk_build_skb() -EOVERFLOW-Fehlerpfad: Das Paket überschreitet MAX_SKB_FRAGS 2) __xsk_generic_xmit()-Nachloop-Bereinigung: Ein ungültiger Deskriptor im TX-Ring verhindert, dass das teilweise übertragene Paket abgeschlossen wird. 3) xsk_release(): Socket-Schließung während xs->skb ein unvollständiges Paket enthält
In allen drei Fällen wurden die TX-Deskriptoren für die bereits verarbeiteten Fragmente aus dem TX-Ring verbraucht (xskq_cons_release), und CQ-Slots wurden reserviert. Allerdings ruft xsk_drop_skb() xsk_consume_skb() auf, was die CQ-Reservierungen über xsk_cq_cancel_locked() storniert. Da die Buffer-Adressen niemals in der Completion Queue erscheinen, verliert Userspace dauerhaft den Überblick über diese Buffer.
Dies wird behoben, indem consume_skb() ausgelöst wird, um den vorhandenen XSK-Zerstörer (destructor) xsk_destruct_skb aufzurufen, der bereits Buffer-Adressen an die CQ übermittelt, indem er xsk_cq_submit_addr_locked() aufruft.
Beachten Sie, dass das Zurückstornieren der Deskriptoren in den TX-Ring (über xskq_cons_cancel_n) keine geeignete Option ist, da ein überdimensioniertes Paket, das MAX_SKB_FRAGS immer überschreitet, unendlich oft erneut versucht würde, was offensichtlich zu einem Deadlock im TX-Pfad führen würde.
Außerdem wird die Zuweisung von desc->addr in xsk_build_skb() oberhalb der Überlaufprüfung verschoben, sodass die Adresse des aktuellen Deskriptors aufgezeichnet wird, bevor ein potenzieller -EOVERFLOW-Sprung nach free_err erfolgt, konsistent mit dem Zero-Copy-Pfad in xsk_build_skb_zerocopy().
[1]: https://lore.kernel.org/all/[email protected]/
If you want to get best quality of vulnerability data, you may have to visit VulDB.