VulnerabilityPublished 18 Oct 2026

CVE-2026-98438: Linux kernel · mptcp: options: fix uninit-value in mptcp_write_data_fin

Source GCVE Database

Authoritative record:CVE-2026-98438· Medium

Not known to be exploited : upgrade to b110f1dd6cb6a9930503354a01a315e0a821eaa7 or 9a682067dd7b9dce6b94a0a05661dcc921446402 when convenient.

Data as of 26 Oct 2026, 14:05 UTC

Severity

Medium

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS: 0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in b110f1dd6cb6a9930503354a01a315e0a821eaa7, 9a682067dd7b9dce6b94a0a05661dcc921446402

Exploitation evidence

Disclosed: evidence found.
CVE published 18 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

ghsa-232g-622w-prrg

What to do

Upgrade Linux kernel to b110f1dd6cb6a9930503354a01a315e0a821eaa7 or 9a682067dd7b9dce6b94a0a05661dcc921446402.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ cfcceb7a39fc10a6f896af8229bf81d96acb22cc, < b110f1dd6cb6a9930503354a01a315e0a821eaa7	Fixed in b110f1dd6cb6a9930503354a01a315e0a821eaa7
LinuxLinux	Affected ≥ cfcceb7a39fc10a6f896af8229bf81d96acb22cc, < 9a682067dd7b9dce6b94a0a05661dcc921446402	Fixed in 9a682067dd7b9dce6b94a0a05661dcc921446402
LinuxLinux	Affected =7.1	Fixed in–

AI-suggested

A fix has been applied to the Linux kernel to properly initialize the checksum and related fields in the mptcp_write_data_fin function. Users should update to the fixed kernel version once it is available. No other mitigation steps are indicated.

Description

A vulnerability in the Linux kernel's Multipath TCP (MPTCP) implementation related to uninitialized values in the mptcp_write_data_fin function has been resolved. The issue occurs when sending a DATA_FIN without data, where certain checksum fields were not properly initialized due to changes in packet processing code. This could lead to incorrect packet formation.

Impact

Improper initialization of checksum fields in MPTCP packets could lead to malformed packets being sent, potentially causing communication issues or protocol errors. There is no indication of active exploitation or direct security compromise from this vulnerability in the provided data.

Summary

The vulnerability involves the MPTCP options handling in the Linux kernel, specifically in the mptcp_write_data_fin function. When a DATA_FIN segment without data is sent, it occupies one octet of the connection-level sequence space and requires adding a DSS mapping with specific values. If checksum negotiation is enabled, the checksum must be computed and included in the packet, requiring the initial checksum data to be reset to zero. A recent kernel commit changed the behavior so that the ext_copy structure is no longer zeroed by default, causing the checksum field to remain uninitialized in this case. The fix initializes the checksum and related fields properly for this specific scenario.

References

Community reviews

Loading reviews…