CVE-2026-90054

tcp: fix corruption of urgent data on multi-segment retransmit

N/A
Published: September 17, 2026 at 04:05 PM UTC
Updated: October 19, 2026 at 09:18 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: /* tcp_write_xmit() */ limit = mss_now; if (tso_segs > 1 && !tcp_urg_mode(tp)) limit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: /* __tcp_retransmit_skb() */ len = cur_mss * segs; /* segs > 1, no urg_mode check */ ... /* tcp_gso_segment(): bumps seq only, urg_ptr is copied */ urg_ptr is an offset from the segment's own seq, so a copied value points at a different place on each segment. The receiver rebuilds the absolute urgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead of the one OOB byte: seg1 seq 1 urg_ptr 5001 -> urgent @ 5001 (ok) seg2 seq 1001 urg_ptr 5001 -> urgent @ 6001 (wrong, +MSS) seg3 seq 2001 urg_ptr 5001 -> urgent @ 7001 (wrong, +2*MSS) The real OOB byte is never pointed at, so the receiver stops splicing it out and delivers it as normal in-band data, corrupting the stream. Guard the retransmit length like the xmit path: keep segs = 1 while in urgent mode.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

10d3be569243def8d92ac3722395ef5a59c504e64.7
Vendor states this is fixed in 3d4e005c198dc410ad568f832bffa7569c059ff8 (fixed)
Vendor states this is fixed in 47eb90299e6882d6445672530dd7c51ac33ebdbd (fixed)
Vendor states this is fixed in 4fd2ee4ac154c204d95d8db72221446dac5af9b8 (fixed)
Vendor states this is fixed in 711bfd762bec05fb19bc3b17cbb157c39f4e66da (fixed)
Vendor states this is fixed in 8eb51013b6308870479a64b4a2a018697b997849 (fixed)
Vendor states this is fixed in b8f08a94b2a4addc39249dcf9c792e786108621b (fixed)
Vendor states this is fixed in ce2b807f42ed5e55567b8864ab72963f90779270 (fixed)
Vendor states this is fixed in ebe55406404f3cb28e36d2b668e2c6c05026ec29 (fixed)
Vendor states this is fixed in 4.7 (unaffected)
Vendor states this is fixed in 5.10.270 (unaffected)
Vendor states this is fixed in 5.15.221 (unaffected)
Vendor states this is fixed in 6.1.188 (unaffected)
Vendor states this is fixed in 6.12.110 (unaffected)
Vendor states this is fixed in 6.18.52 (unaffected)
Vendor states this is fixed in 6.6.157 (unaffected)
Vendor states this is fixed in 7.2.6 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card