CVE-2022-49872 in Linux
Zusammenfassung
von VulDB • 08.06.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
net: gso: Behebung eines Panics bei frag_list mit gemischten head_alloc-Typen
Seit dem Commit 3dcbdb134f32 („net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") ist es erlaubt, die gso_size eines GRO-Pakets zu ändern. Dieser Commit geht jedoch davon aus, dass „das Überprüfen des ersten list_skb-Mitglieds ausreicht; d. h., wenn eines der list_skb-Mitglieder einen head mit non head_frag hat, dann hat auch das erste Mitglied dies".
Es hat sich herausgestellt, dass diese Annahme nicht zutrifft. Wir haben beobachtet, dass ein BUG_ON in skb_segment ausgelöst wurde, als die skbs auf der frag_list unterschiedliche head_frag-Werte im Zusammenhang mit dem vmxnet3-Treiber aufwiesen. Dies geschieht, weil __netdev_alloc_skb und __napi_alloc_skb je nach angeforderter Größe ein skb zurückgeben können, das entweder seitenbasiert (page backed) oder mit kmalloc allokiert ist. Infolgedessen kann das letzte kleine skb im GRO-Paket mit kmalloc allokiert sein.
Es gibt drei verschiedene Orte, an denen dies behoben werden kann:
(1) Wir könnten head_frag in GRO überprüfen und GROing von skbs mit unterschiedlichem head_frag nicht erlauben. Dies würde jedoch zu einer Performance-Regression auf normalen Forward-Pfaden mit unveränderter gso_size führen, bei denen !head_frag im letzten Paket kein Problem darstellt.
(2) Festlegen eines Flags in bpf_skb_net_grow und bpf_skb_net_shrink, das anzeigt, dass NETIF_F_SG unerwünscht ist. Dies würde erfordern, ein Bit in sk_buff zu verbrauchen. Darüber hinaus kann dieses Flag zurückgesetzt werden, wenn alle skbs auf der frag_list seitenbasiert sind. Um eine gute Performance beizubehalten, müsste bpf_skb_net_grow/shrink die frag_list durchlaufen.
(3) Durchlaufen der frag_list in skb_segment bei der Bestimmung, ob NETIF_F_SG zurückgesetzt werden soll. Dies verlangsamt die Dinge natürlich.
Dieser Patch implementiert (3). Um die Performance-Auswirkungen in skb_segment zu begrenzen, wird die Liste nur für skbs mit gesetztem SKB_GSO_DODGY durchlaufen, deren gso_size geändert wurde. Normale Pfade werden dies also nicht betreffen.
Wir könnten nur das letzte skb überprüfen, aber da wir ohnehin die gesamte Liste durchlaufen müssen, bleiben wir auf der sicheren Seite.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.