CVE-2026-43503

Zusammenfassung

Im Linux-Kernel wurde die folgende Schwachstelle behoben: net: skbuff: Shared-Frag-Marker durch die Frag-Transfer-Helfer propagieren Zwei Frag-Transfer-Helfer (__pskb_copy_fclone() und skb_shift()) propagieren das SKBFL_SHARED_FRAG-Bit in skb_shinfo()->flags nicht, wenn Fragmente von der Quelle zum Ziel verschoben werden. __pskb_copy_fclone() überlässt die übrigen Shinfo-Metadaten nach dem Kopieren der Frag-Deskriptoren skb_copy_header(), aber dieser Helfer überträgt nur gso_{size,segs,type} und berührt skb_shinfo()->flags nie; skb_shift() verschiebt Frag-Deskriptoren direkt und lässt die Flags unberührt. Infolgedessen behält das Ziel-skb eine Referenz auf dieselben extern gehörenden oder vom Page-Cache gestützten Seiten, während skb_has_shared_frag() fälschlich false meldet. Die Diskrepanz ist für jeden In-Place-Schreiber schädlich, der skb_has_shared_frag() verwendet, um zu entscheiden, ob gemeinsame Seiten über skb_cow_data() umgeleitet werden müssen. ESP-Eingabe ist ein solcher Schreiber (esp4.c, esp6.c), und eine einzige nft-Regel 'dup to <local>' – oder jeder andere nf_dup_ipv4()/xt_TEE-Aufrufer – genügt, um ein per pskb_copy() erzeugtes skb ohne den Marker in esp_input() zu bringen, wodurch ein unprivilegierter Benutzer über verirrte authencesn-ESN-Schreibzugriffe in den Page-Cache einer root gehörenden, schreibgeschützten Datei schreiben kann. Setze SKBFL_SHARED_FRAG auf dem Ziel, wann immer Frag-Deskriptoren tatsächlich von der Quelle verschoben wurden. skb_copy() und skb_copy_expand() teilen sich ebenfalls skb_copy_header(), linearisieren aber alle gepaginaten Daten in neu zugewiesenen Head-Speicher und enden mit nr_frags == 0, sodass skb_has_shared_frag() von selbst false zurückgibt; sie benötigen keine Änderung. Dieselbe Auslassung existiert in skb_gro_receive() und skb_gro_receive_list(). Ersteres verschiebt die Frag-Deskriptoren des eingehenden skb über zwei Pfade (eine direkte Frag-Verschiebeschleife und den head_frag- + memcpy-Pfad) in das letzte Sub-skb des Akkumulators; letzteres hängt das eingehende skb vollständig an die frag_list von p an. Nachgelagert liest skb_segment() nur skb_shinfo(p)->flags, und skb_segment_list() verwendet das Shinfo jedes Sub-skb erneut als nskb – sowohl p als auch lp müssen den Marker tragen. Dieselbe Auslassung existiert auch in tcp_clone_payload(), das ein MTU-Probe-skb erstellt, indem es Frag-Deskriptoren von skbs auf sk_write_queue in ein neu zugewiesenes nskb verschiebt. Der Helfer fällt in dieselbe Familie und verdient aus Konsistenzgründen dieselbe Korrektur; derzeit ist kein TCP-TX-seitiger In-Place-Schreiber bekannt, der über diese Lücke eine Benutzerseite erreicht, aber ein künftiger Konsument, der sich auf den Marker verlässt, würde still regressieren. Dieselbe Auslassung existiert in skb_segment(): Das Flag-Merging pro Iteration übernimmt nur das Flag von head_skb, und der innere switch, der frag_skb bei Erschöpfung der head_skb-Fragmente an list_skb zurückbindet, faltet das Flag des neuen frag_skb nicht in nskb. Falte das Flag von frag_skb an beiden Stellen, sodass Segmente, die Fragmente aus frag_list-Mitgliedern beziehen, den Marker tragen.