Title: Linux, Description: En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:

net: skbuff: propagar el marcador de fragmento compartido a través de los ayudantes de transferencia de fragmentos

Dos ayudantes de transferencia de fragmentos (__pskb_copy_fclone() y skb_shift()) no logran propagar el bit SKBFL_SHARED_FRAG en skb_shinfo()->flags al mover fragmentos del origen al destino. __pskb_copy_fclone() difiere el resto de los metadatos de shinfo a skb_copy_header() después de copiar los descriptores de fragmentos, pero ese ayudante solo transfiere gso_{size,segs,type} y nunca toca skb_shinfo()->flags; skb_shift() mueve los descriptores de fragmentos directamente y deja las banderas intactas. Como resultado, el skb de destino mantiene una referencia a las mismas páginas de propiedad externa o respaldadas por la caché de páginas mientras informa skb_has_shared_frag() como falso.

La falta de coincidencia es perjudicial en cualquier escritor in situ que utiliza skb_has_shared_frag() para decidir si las páginas compartidas deben desviarse a través de skb_cow_data(). La entrada ESP es uno de esos escritores (esp4.c, esp6.c), y una única regla nft 'dup to <local>' -- o cualquier otro llamador de nf_dup_ipv4() / xt_TEE -- es suficiente para que un skb copiado con pskb_copy() llegue a esp_input() con el marcador eliminado, permitiendo que un usuario sin privilegios escriba en la caché de páginas de un archivo de solo lectura propiedad de root a través de escrituras errantes de authencesn-ESN.

Establecer SKBFL_SHARED_FRAG en el destino siempre que los descriptores de fragmentos se hayan movido realmente del origen. skb_copy() y skb_copy_expand() también comparten skb_copy_header() pero linealizan todos los datos paginados en almacenamiento de cabecera recién asignado y emergen con nr_frags == 0, por lo que skb_has_shared_frag() devuelve falso por sí mismo; no necesitan cambios.

La misma omisión existe en skb_gro_receive() y skb_gro_receive_list(). El primero mueve los descriptores de fragmentos del skb entrante al último sub-skb del acumulador a través de dos rutas (un bucle directo de movimiento de fragmentos y la ruta head_frag + memcpy); el segundo encadena el skb entrante completo a la frag_list de p. skb_segment() aguas abajo solo lee skb_shinfo(p)->flags, y skb_segment_list() reutiliza el shinfo de cada sub-skb como el nskb -- tanto p como lp deben llevar el marcador.

La misma omisión también existe en tcp_clone_payload(), que construye un skb de sondeo de MTU moviendo descriptores de fragmentos de skbs en sk_write_queue a un nskb recién asignado. El ayudante pertenece a la misma familia y justifica la misma corrección por coherencia; actualmente no se conoce ningún escritor in situ del lado TX de TCP que alcance una página de usuario a través de esta brecha, pero un futuro consumidor que dependa del marcador regresaría silenciosamente.

La misma omisión existe en skb_segment(): la fusión de banderas por iteración toma solo la bandera de head_skb, y el switch interno que reasigna frag_skb a list_skb al agotarse los fragmentos de head_skb no incorpora la bandera del nuevo frag_skb en nskb. Incorporar la bandera de frag_skb en ambos sitios para que los segmentos que extraen fragmentos de los miembros de frag_list lleven el marcador.