CVE-2026-43503

Linux 커널에서는 다음 취약점이 해결되었습니다.

net: skbuff: 조각 전송 도우미를 통해 공유 조각 마커 전파

두 개의 조각 전송 도우미(__pskb_copy_fclone() 및 skb_shift())가 실패합니다. 다음과 같은 경우 skb_shinfo()->플래그에서 SKBFL_SHARED_FRAG 비트를 전파합니다. 조각을 소스에서 대상으로 이동합니다. _pskb_copy_fclone() 연기 복사 후 shinfo 메타데이터의 나머지 부분을 skb_copy_header()에 넣습니다. 조각 설명자이지만 해당 도우미는 gso{size,segs, type} skb_shinfo()->flags를 건드리지 않습니다. skb_shift() 조각 이동 설명자를 직접 사용하고 플래그를 그대로 둡니다. 그 결과, 대상 skb는 동일한 외부 소유 또는 skb_has_shared_frag()를 다음과 같이 보고하는 동안 페이지 캐시 지원 페이지 거짓.

불일치는 다음을 사용하는 모든 내부 작성기에서 해롭습니다. 공유 페이지를 우회해야 하는지 여부를 결정하는 skb_has_shared_frag() skb_cow_data()를 통해. ESP 입력은 그러한 작성기 중 하나입니다(esp4.c, esp6.c) 및 단일 nft 'dup to ' 규칙 또는 기타 nf_dup_ipv4() / xt_TEE 호출자 - pskb_copy()'d를 실행하기에 충분합니다. 마커가 제거된 esp_input()의 skb를 사용하여 권한이 없는 사용자를 허용합니다. 사용자는 다음을 통해 루트 소유의 읽기 전용 파일의 페이지 캐시에 씁니다. authencesn-ESN 스트레이 쓰기.

조각 설명자가 있을 때마다 대상에 SKBFL_SHARED_FRAG를 설정합니다. 실제로 소스에서 이동되었습니다. skb_copy() 및 skb_copy_expand() skb_copy_header()도 공유하지만 페이징된 모든 데이터를 새로 선형화합니다. 헤드 스토리지를 할당하고 nr_frags == 0으로 나타납니다. skb_has_shared_frag()는 자체적으로 false를 반환합니다. 변화가 필요하지 않습니다.

skb_gro_receive() 및 skb_gro_receive_list()에도 동일한 누락이 존재합니다. 전자는 들어오는 skb의 조각 설명자를 두 경로(직접 조각 이동 루프 및 head_frag + memcpy 경로); the latter chains the incoming skb whole p의 frag_list에 추가하세요. 다운스트림 skb_segment() 읽기 전용 skb_shinfo(p)->flags 및 skb_segment_list()는 각 하위 skb의 플래그를 재사용합니다. nskb로서의 shinfo - p와 lp 모두 마커를 전달해야 합니다.

동일한 누락이 tcp_clone_payload()에도 존재합니다. sk_write_queue의 skbs에서 조각 설명자를 이동하여 MTU 프로브 skb 새로 할당된 nskb에 넣습니다. 도우미는 같은 가족에 속합니다 일관성을 위해 동일한 수정을 보장합니다. TCP TX 측 내부 없음 작가는 현재 이 틈을 통해 사용자 페이지에 도달하는 것으로 알려져 있지만, 마커에 의존하는 미래의 소비자는 조용히 퇴보할 것입니다.

skb_segment()에도 동일한 누락이 존재합니다: 반복당 플래그 병합은 head_skb의 플래그와 리바인드하는 내부 스위치만 사용합니다. head_skb-frags의 frag_skb에서 list_skb로의 소모는 접히지 않습니다. 새로운 frag_skb의 플래그를 nskb에 추가합니다. 두 사이트 모두에서 frag_skb의 플래그를 접습니다. 따라서 frag_list 멤버의 조각을 그리는 세그먼트에는 마커가 있습니다.