CVE-2026-72021ipvs: use parsed transport offset in SCTP state lookup
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.
- CVSS
- 8.2 HIGH (v3.1, CNA)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 16, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from 2906f66a5682e5670a5eefe991843689b8d8563f before d2b8b1557ec07ea1bb5dddbceaf4dfe63d388e27; 2906f66a5682e5670a5eefe991843689b8d8563f builds before 9f94573ab962a9e81954b755da016fa3cd2f5039; 2906f66a5682e5670a5eefe991843689b8d8563f builds before 290e9e8389b556efc603522e28bd1543846aa336; 2906f66a5682e5670a5eefe991843689b8d8563f builds before 9cb5ac594ca76d3a71803b23b74c835b0721e628; from 2906f66a5682e5670a5eefe991843689b8d8563f before a4a2d2e483d79cc2ad3a170674cf159644acf22b; 2906f66a5682e5670a5eefe991843689b8d8563f builds before 247d055504dcc852e539b9f7f30d19f9741474bf; from 2906f66a5682e5670a5eefe991843689b8d8563f before e5d0bb8871668f20de8f3c94b5ae3f372346bc6e; 2906f66a5682e5670a5eefe991843689b8d8563f builds before 2f75c0faa3361b28e36cc0512b3299e163e25789 | CNA record |
References
- https://git.kernel.org/stable/c/d2b8b1557ec07ea1bb5dddbceaf4dfe63d388e27
- https://git.kernel.org/stable/c/9f94573ab962a9e81954b755da016fa3cd2f5039
- https://git.kernel.org/stable/c/290e9e8389b556efc603522e28bd1543846aa336
- https://git.kernel.org/stable/c/9cb5ac594ca76d3a71803b23b74c835b0721e628
- https://git.kernel.org/stable/c/a4a2d2e483d79cc2ad3a170674cf159644acf22b
- https://git.kernel.org/stable/c/247d055504dcc852e539b9f7f30d19f9741474bf
- https://git.kernel.org/stable/c/e5d0bb8871668f20de8f3c94b5ae3f372346bc6e
- https://git.kernel.org/stable/c/2f75c0faa3361b28e36cc0512b3299e163e25789
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.