CVE-2026-43503

Резюме

В ядре Linux устранена следующая уязвимость: net: skbuff: передавать маркер общего фрагмента через вспомогательные функции переноса фрагментов Две вспомогательные функции переноса фрагментов (`__pskb_copy_fclone()` и `skb_shift()`) не распространяют бит `SKBFL_SHARED_FRAG` в `skb_shinfo()->flags` при перемещении фрагментов из источника в назначение. `__pskb_copy_fclone()` откладывает остальную часть метаданных `shinfo` на `skb_copy_header()` после копирования дескрипторов фрагментов, но эта вспомогательная функция переносит только `gso_{size,segs,type}` и никогда не трогает `skb_shinfo()->flags`; `skb_shift()` перемещает дескрипторы фрагментов напрямую и оставляет флаги нетронутыми. В результате целевой `skb` сохраняет ссылку на те же страницы, принадлежащие внешнему владельцу или подкреплённые страничным кэшем, при этом `skb_has_shared_frag()` возвращает `false`. Такое несоответствие вредно для любого механизма записи на месте, который использует `skb_has_shared_frag()`, чтобы решить, нужно ли переводить общие страницы через `skb_cow_data()`. Ввод ESP является одним из таких механизмов записи (`esp4.c`, `esp6.c`), и одного правила nft `'dup to <local>'` — или любого другого вызова `nf_dup_ipv4()` / `xt_TEE` — достаточно, чтобы `skb`, полученный через `pskb_copy()`, попал в `esp_input()` со снятым маркером, что позволяет непривилегированному пользователю записывать в страничный кэш доступного только для чтения файла, принадлежащего root, через побочные записи authencesn-ESN. Устанавливайте `SKBFL_SHARED_FRAG` в целевом `skb` всякий раз, когда дескрипторы фрагментов действительно были перемещены из источника. `skb_copy()` и `skb_copy_expand()` также используют `skb_copy_header()`, но линеаризуют все страничные данные во вновь выделенную область заголовка и завершают работу с `nr_frags == 0`, поэтому `skb_has_shared_frag()` возвращает `false` самостоятельно; их менять не нужно. Та же ошибка присутствует в `skb_gro_receive()` и `skb_gro_receive_list()`. Первая перемещает дескрипторы фрагментов входящего `skb` в последний sub-skb сумматора двумя путями (непосредственный цикл перемещения фрагментов и путь `head_frag` + `memcpy`); вторая целиком присоединяет входящий `skb` к `frag_list` элемента `p`. Последующий `skb_segment()` читает только `skb_shinfo(p)->flags`, а `skb_segment_list()` повторно использует `shinfo` каждого sub-skb в качестве `nskb` — и `p`, и `lp` должны нести маркер. Та же ошибка присутствует и в `tcp_clone_payload()`, которая создаёт пробный MTU-пакет, перемещая дескрипторы фрагментов из `skbs` в `sk_write_queue` во вновь выделенный `nskb`. Эта функция относится к тому же семейству и заслуживает того же исправления для согласованности; в настоящее время ни один известный механизм записи на стороне отправки TCP не достигает пользовательской страницы через этот пробел, но будущий потребитель, полагающийся на этот маркер, незаметно деградировал бы. Та же ошибка присутствует в `skb_segment()`: при каждой итерации объединение флагов берёт только флаг `head_skb`, а внутренний `switch`, который при исчерпании фрагментов `head_skb` повторно привязывает `frag_skb` к `list_skb`, не включает флаг нового `frag_skb` во флаги `nskb`. Добавьте флаг `frag_skb` в обоих местах, чтобы сегменты, берущие фрагменты из элементов `frag_list`, несли маркер.