GHSA-CWQ3-366F-G758

Vulnerability from github – Published: 2026-09-17 18:31 – Updated: 2026-09-17 18:31
VLAI
Details

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.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-90054"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-17T17:16:53Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix corruption of urgent data on multi-segment retransmit\n\nOn the normal xmit path, while in urgent mode we refuse to build a\nmulti-segment TSO packet, so every segment gets its own urg_ptr:\n\n\t/* tcp_write_xmit() */\n\tlimit = mss_now;\n\tif (tso_segs \u003e 1 \u0026\u0026 !tcp_urg_mode(tp))\n\t\tlimit = tcp_mss_split_point(...);\n\nThe retransmit path has no such guard. __tcp_retransmit_skb() builds a\nsegs \u003e 1 skb and hands it to the GSO layer, which only advances th-\u003eseq\nper segment and copies urg_ptr verbatim:\n\n\t/* __tcp_retransmit_skb() */\n\tlen = cur_mss * segs;\t\t/* segs \u003e 1, no urg_mode check */\n\t...\n\t/* tcp_gso_segment(): bumps seq only, urg_ptr is copied */\n\nurg_ptr is an offset from the segment\u0027s own seq, so a copied value points\nat a different place on each segment. The receiver rebuilds the absolute\nurgent seq as seg.seq + urg_ptr, so it walks a moving urgent point instead\nof the one OOB byte:\n\n\tseg1  seq 1     urg_ptr 5001 -\u003e urgent @ 5001   (ok)\n\tseg2  seq 1001  urg_ptr 5001 -\u003e urgent @ 6001   (wrong, +MSS)\n\tseg3  seq 2001  urg_ptr 5001 -\u003e urgent @ 7001   (wrong, +2*MSS)\n\nThe real OOB byte is never pointed at, so the receiver stops splicing it\nout and delivers it as normal in-band data, corrupting the stream.\n\nGuard the retransmit length like the xmit path: keep segs = 1 while in\nurgent mode.",
  "id": "GHSA-cwq3-366f-g758",
  "modified": "2026-09-17T18:31:48Z",
  "published": "2026-09-17T18:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90054"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3d4e005c198dc410ad568f832bffa7569c059ff8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/47eb90299e6882d6445672530dd7c51ac33ebdbd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4fd2ee4ac154c204d95d8db72221446dac5af9b8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/711bfd762bec05fb19bc3b17cbb157c39f4e66da"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8eb51013b6308870479a64b4a2a018697b997849"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b8f08a94b2a4addc39249dcf9c792e786108621b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce2b807f42ed5e55567b8864ab72963f90779270"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ebe55406404f3cb28e36d2b668e2c6c05026ec29"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.