CVE-2026-98549

W jądrze Linuksa usunięto następującą lukę:

tcp: zapobiegaj zwijaniu się skbsów przez granicę w kolejce rtx

tcp_write_collapse_fence() ustawia TCP_SKB_CB(skb)->eor = 1 na
tcp_write_queue_tail(sk), aby zapobiec kolejce skbs po przełączeniu na
szyfrowanie urządzenia przed zwinięciem do wcześniejszych skbs.

Ogrodzenie nie ma sensu, jeśli wszystkie wcześniejsze dane zostały już przesłane
kiedy nastąpi przełączenie: sk->sk_write_queue jest pusty. Jeszcze nie
potwierdzono wcześniej, że skbs czeka w sk->tcp_rtx_queue z eor 0.

Podczas kolejnej retransmisji lub zmiany SACK, tcp_retrans_try_collapse() lub
tcp_shift_skb_data() może następnie połączyć skb oczekujący w kolejce po przełączeniu na
jeden stał przed nim w kolejce.

Dotyczy to obu użytkowników ogrodzenia:

- psp: urządzenia szyfrują skbs tylko za pomocą zestawu skb->deszyfrowany. Połączony skb
pozostaje odszyfrowany = 0 z wcześniejszego skb, więc scalone dane są wysyłane później
psp_sock_assoc_set_tx() jest retransmitowany w postaci zwykłego tekstu.

- odciążenie urządzenia tls: połączony skb znajduje się nad ustawionym znacznikiem startu
tls_set_device_offload(). Rozwiązanie programowe (fill_sg_in()) zwraca
-EINVAL), a sterowniki mlx5, nfp i funeth nie obsługują takich plików
skb i upuść go. Każda retransmisja odbudowuje ten sam skb, więc plik
stragany przyłączeniowe.

Napraw to w dwóch miejscach, aby zapewnić głęboką obronę:

1. Wróć do tcp_rtx_queue_tail(sk) w tcp_write_collapse_fence()
gdy tcp_write_queue_tail(sk) ma wartość NULL.

2. Sprawdź !skb_cmp_decrypted(to, from) w tcp_skb_can_collapse(), ponieważ
tcp_skb_can_collapse_rx() wykonuje po odebraniu. skb_shift(), które oba
zwiń ścieżki, ma już do tego funkcję DEBUG_NET_WARN_ON_ONCE().
stan.