CVSS 3.1
Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)
Атакува се
Време до експлоатация
Атакува се по мрежата, без особени условия, без вход и без действие от потребителя.
- Експлоатация: няма данни за експлоатация
- Атаката може да се автоматизира
Описание
Оригинално описание
In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok <ok>| ok ok ok <x> \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets
Засегнати продукти
- Linux Linux: 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди ae3f627b45fbc3c776a4e484696f3cad7cbb4eca; 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди 0c9de092ef8c50a7ee9612811566f0aa81d8d7b6; 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди 56bd32c0edca34041a5c215887fcf562fae2e2db; 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди 9ac6aebef4b4bfc5ed408b0b65645981574bc780; 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди ea5d7787635e26ec1194ec7eec0e8e5ae3bd10a5; 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди 4cb163e9efcac4cd35c3043e097f25081a5c015c; 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди c86901d22c89a6bf4e2f013e948aaabc60869893; 1f59533f9ca5634e7b8914252e48aee9d9cbe501 преди 7aa767d0d3d04e50ae94e770db7db8197f666970
- Linux Linux: 3.18; преди 3.18; 5.10.252 до 5.10.*; 5.15.202 до 5.15.*; 6.1.165 до 6.1.*; 6.6.128 до 6.6.*; 6.12.75 до 6.12.*; 6.18.16 до 6.18.*; 6.19.6 до 6.19.*; от 7.0 нататък
Вид слабост
История
- 6 май 2026 Публикувано
Други уязвимости в Linux Linux
Първоизточници
- https://www.cve.org/CVERecord?id=CVE-2026-43194
- https://nvd.nist.gov/vuln/detail/CVE-2026-43194
- https://git.kernel.org/stable/c/ae3f627b45fbc3c776a4e484696f3cad7cbb4eca
- https://git.kernel.org/stable/c/0c9de092ef8c50a7ee9612811566f0aa81d8d7b6
- https://git.kernel.org/stable/c/56bd32c0edca34041a5c215887fcf562fae2e2db
- https://git.kernel.org/stable/c/9ac6aebef4b4bfc5ed408b0b65645981574bc780
- https://git.kernel.org/stable/c/ea5d7787635e26ec1194ec7eec0e8e5ae3bd10a5
- https://git.kernel.org/stable/c/4cb163e9efcac4cd35c3043e097f25081a5c015c
- https://git.kernel.org/stable/c/c86901d22c89a6bf4e2f013e948aaabc60869893
- https://git.kernel.org/stable/c/7aa767d0d3d04e50ae94e770db7db8197f666970