CVE-2026-43503

Riepilogo

Nel kernel Linux è stata risolta la seguente vulnerabilità: net: skbuff: propagate shared-frag marker through frag-transfer helpers Due helper di trasferimento dei frag (`__pskb_copy_fclone()` e `skb_shift()`) non propagano il bit `SKBFL_SHARED_FRAG` in `skb_shinfo()->flags` quando spostano i frag dalla sorgente alla destinazione. `__pskb_copy_fclone()` rimanda il resto dei metadati shinfo a `skb_copy_header()` dopo aver copiato i descrittori dei frag, ma quell'helper trasferisce solo `gso_{size,segs,type}` e non tocca mai `skb_shinfo()->flags`; `skb_shift()` sposta direttamente i descrittori dei frag e lascia i flag intatti. Di conseguenza, lo skb di destinazione mantiene un riferimento alle stesse pagine di proprietà esterna o supportate da page cache, pur riportando `skb_has_shared_frag()` come falso. La discrepanza è dannosa in qualsiasi writer in-place che usi `skb_has_shared_frag()` per decidere se le pagine condivise debbano essere deviate tramite `skb_cow_data()`. L'input ESP è uno di questi writer (`esp4.c`, `esp6.c`), e una singola regola `nft 'dup to <local>'` — o qualsiasi altro chiamante di `nf_dup_ipv4()` / `xt_TEE` — è sufficiente per far arrivare uno skb copiato con `pskb_copy()` in `esp_input()` con il marker rimosso, consentendo a un utente non privilegiato di scrivere nella page cache di un file di sola lettura di proprietà di root tramite scritture spurie authencesn-ESN. Impostare `SKBFL_SHARED_FRAG` sulla destinazione ogni volta che i descrittori dei frag sono stati effettivamente spostati dalla sorgente. Anche `skb_copy()` e `skb_copy_expand()` condividono `skb_copy_header()`, ma linearizzano tutti i dati paginati in uno storage head appena allocato e si ritrovano con `nr_frags == 0`, quindi `skb_has_shared_frag()` restituisce falso di per sé; non necessitano di modifiche. La stessa omissione esiste in `skb_gro_receive()` e `skb_gro_receive_list()`. Il primo sposta i descrittori dei frag dello skb in ingresso nell'ultimo sub-skb dell'accumulatore tramite due percorsi (un ciclo diretto di spostamento dei frag e il percorso `head_frag` + `memcpy`); il secondo concatena l'intero skb in ingresso alla `frag_list` di `p`. A valle, `skb_segment()` legge solo `skb_shinfo(p)->flags`, e `skb_segment_list()` riutilizza lo shinfo di ogni sub-skb come nskb — sia `p` che `lp` devono avere il marker. La stessa omissione esiste anche in `tcp_clone_payload()`, che costruisce uno skb probe MTU spostando i descrittori dei frag dagli skb su `sk_write_queue` in un nskb appena allocato. L'helper rientra nella stessa famiglia e merita la stessa correzione per coerenza; al momento non è noto alcun writer in-place lato TX di TCP che raggiunga una pagina utente attraverso questa falla, ma un futuro consumatore che dipenda dal marker regredirebbe silenziosamente. La stessa omissione esiste in `skb_segment()`: la fusione dei flag a ogni iterazione prende solo il flag di `head_skb`, e lo switch interno che riassocia `frag_skb` a `list_skb` quando i frag di `head_skb` sono esauriti non include il flag del nuovo `frag_skb` in nskb. Includere il flag di `frag_skb` in entrambi i punti, così che i segmenti che prelevano frag dai membri di `frag_list` abbiano il marker.