CVE-2026-98300

Executive Summary

CVE-2026-98300 is a race condition in the Linux kernel's IPv6 TCP receive path. Between the time tcp_v6_rcv() hands a packet to tcp_v6_do_rcv() and the moment the socket state is re-read, a concurrent close() can transition the socket from TCP_LISTEN to TCP_CLOSE. Because the existing guard only suppresses skb_clone_and_charge_r() for TCP_LISTEN, the socket reaches the clone/charge path locklessly while the sk_forward_alloc accounting is no longer valid, triggering a kernel warning in inet_sock_destruct(). The impact is a kernel memory-accounting inconsistency (sk->sk_forward_alloc imbalance) surfaced at socket destruction, producing a splat/WARN and creating a resource-leak and stability risk rather than a demonstrated remote code-execution primitive.

Technical Analysis

The NVD description for CVE-2026-98300 explains a residual race condition after a previously applied fix. The earlier commit 073d89808c06 ("net: fix data-races around sk->sk_forward_alloc") altered tcp_v6_do_rcv() so that skb_clone_and_charge_r() is no longer invoked for sockets in the TCP_LISTEN state. That change removed the dominant data race on sk->sk_forward_alloc, the per-socket forward-allocation accounting field used by the socket memory accounting subsystem.

The residual window is temporal rather than logical. tcp_v6_rcv() performs an initial state check, and tcp_v6_do_rcv() subsequently re-evaluates the socket. A concurrent close() executing between these two points can flip the socket state from TCP_LISTEN to TCP_CLOSE. When tcp_v6_do_rcv() then executes, the TCP_LISTEN guard no longer matches, so the code proceeds to call skb_clone_and_charge_r() without taking the socket lock (the "locklessly" qualifier in the description). The charge operation mutates sk->sk_forward_alloc while the socket is concurrently being torn down.

The observable symptom in the provided splat is a WARN in inet_sock_destruct() at net/ipv4/af_inet.c:162. inet_sock_destruct() is the AF_INET socket destructor; the WARN is emitted when the forward-allocation accounting is found to be inconsistent during destruction. The trace attributes the hit to ksoftirqd/1 (PID 28) on a PREEMPT(full) kernel, confirming the receive path is executing in softirq context — i.e., the charge occurred on the networking RX softirq path, not in a process context holding the socket lock. The sk->sk_forward_alloc line preceding WARNING: is the diagnostic that identifies which accounting invariant was violated.

The description explicitly notes that for non-listener sockets this behavior is benign: tcp_rcv_state_process() drops the skb for TCP_CLOSE, and the opt_skb was freed immediately anyway. This frames CVE-2026-98300 precisely: it is a leak/accounting-integrity bug scoped to the close-during-RX window on a listening socket, not a data-corruption or memory-safety bug in the traditional sense. Fixing it requires extending the existing state guard to also skip skb_clone_and_charge_r() for TCP_CLOSE, which the description states is acceptable because the downstream TCP_CLOSE handling discards the skb and opt_skb is freed immediately.

Note on schema-boundary gaps: The description does not name the containing function beyond tcp_v6_do_rcv(), does not specify which lock is bypassed, and does not give the release version that carries the fix. The precise commit, the Fixes: tag, and the backport list are not present in the supplied data; we therefore do not assert them.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred strictly from the vulnerability class (TOCTOU race between tcp_v6_rcv()/tcp_v6_do_rcv() and close()) and the mechanics stated in the NVD description.

1. Reconnaissance / target identification. The target surface is any Linux host running a kernel that includes commit 073d89808c06 and has not yet received the follow-up TCP_CLOSE guard. Externally observable requirements are minimal: an IPv6 TCP listener reachable by the attacker, and the ability to open and close connections on that listener without authentication. IPv6 reachability (or the ability to reach the host over IPv6) is the key precondition; a dual-stack listener accepting IPv6 satisfies it. Fingerprinting is via a standard TCP port probe over IPv6; no product-specific banner is required because the vulnerable code is in the core kernel stack, not an application.

2. Triggering the race. The attacker opens connections to the IPv6 listener and repeatedly closes them at high rate while simultaneously sending data-bearing segments that reach tcp_v6_rcv()/tcp_v6_do_rcv(). The goal is to land a packet in the narrow inter-function window such that the concurrent close() has already moved the socket to TCP_CLOSE by the time tcp_v6_do_rcv() executes its state check. Because the description states skb_clone_and_charge_r() is called "locklessly" in this window, the attacker does not need to corrupt the packet or exploit an application parser — the race is between two kernel paths, not between attacker bytes and vulnerable code. The sent segment only needs to be a valid TCP segment accepted by the listener; it is the timing of the close() relative to the receive path that matters.

3. Payload/execution method. There is no payload in the conventional sense. The "execution" is the attacker-controlled scheduling of close() against tcp_v6_do_rcv(). Repeated attempts incrementally perturb sk->sk_forward_alloc on sockets that are already doomed to destruction. Success is observed indirectly: the kernel emits the inet_sock_destruct() WARN and the sk->sk_forward_alloc diagnostic, and in some runs the forward-allocation accounting for the socket is left out of balance through destruction.

4. Post-exploitation impact. The realized impact is a kernel WARN splat and an accounting inconsistency in the socket memory subsystem. Repeated triggering can leak forward-allocation accounting for the affected sockets, which under sustained abuse contributes to memory-accounting drift and, in the limit, resource exhaustion of the affected socket-memory accounting path. There is no evidence in the provided data of memory corruption, use-after-free, privilege escalation, or remote code execution, and no exploit code exists. The realistic post-exploitation outcome for an attacker with an IPv6 path to the listener is therefore denial-of-service pressure and noisy log/kernel-message generation rather than a takeover primitive.

Impact Assessment

The impact profile is narrow and availability-oriented. There is no CVSS score or vector assigned in the supplied data (NVD: N/A; CNA: none). Based strictly on the description, the plausible subscore direction is High availability impact (A:H) — a kernel WARN and potential accounting/resource drift under repeated triggering. Confidentiality and integrity impact is not derivable: the description documents only sk_forward_alloc imbalance and the destructor WARN, not data exposure or corruption. Exploitability is constrained by the race window: the attacker must win a narrow inter-function interval multiple times, and must have an IPv6 TCP listener and an IPv6 path to it, which supports a High attack complexity (AC:H) rating and an AV:N rating (network-delivered IPv6 segments). Privileges and user interaction: PR:N / UI:N (the attacker needs no local account and no victim action). Scope is assumed S:U because the impact is confined to socket accounting on the affected host and no scope change is documented. This places an inferred vector near CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H (6.5 Moderate), which the report carries as an inference only — the authoritative score is N/A and must not be overridden.

Blast radius: every affected host running the impacted kernel build with an IPv6 TCP listener. The exposure is per-host, not per-tenant, since the vulnerable code is kernel-global. Systems with IPv6 disabled are not reachable via the documented path. Given the ubiquity of the Linux kernel, the affected-system count is very high; however, the reachability precondition (IPv6-reachable listener plus a successful race) substantially limits which of those systems are practically exposed. CISA KEV: NO — no in-the-wild exploitation is recorded. No EPSS score has been assigned by FIRST.org; no EPSS value is asserted here.

Detection Guidance

Detection for a race-condition WARN is primarily host-side and log/kernel-message based, complemented by network telemetry for the IPv6 SYN/close churn characteristic of a triggering campaign.

Sigma Rule

title: Linux Kernel TCP IPv6 Race Condition Warning (CVE-2026-98300)
id: 3f9a2c7e-8b14-4d6a-9e21-7c1b5a0d4f88
status: experimental
description: Detects kernel WARN in inet_sock_destruct indicating sk_forward_alloc imbalance (CVE-2026-98300)
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-98300
author: valtersit.com
logsource:
  product: linux
  service: kernel
detection:
  selection_warn:
    - "inet_sock_destruct"
    - "sk_forward_alloc"
  selection_ctx:
    - "af_inet.c:162"
    - "tcp_v6_do_rcv"
  condition: selection_warn or selection_ctx
falsepositives:
  - Other socket accounting bugs producing similar destructor warnings
  - Kernel developers exercising the receive path under fault injection
level: high

YARA Rule

rule CVE_2026_98300_tcp_v6_close_race
{
    meta:
        author = "valtersit.com"
        description = "Detects kernel log / text artifacts of the CVE-2026-98300 tcp_v6_do_rcv close() race warning"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-98300"
        date = "2026-01-01"
    strings:
        $a = "inet_sock_destruct" ascii wide
        $b = "sk_forward_alloc" ascii wide
        $c = "tcp_v6_do_rcv" ascii wide
        $d = "af_inet.c:162" ascii wide
    condition:
        any of them
}

Suricata IDS Rule

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"CVE-2026-98300 Possible IPv6 TCP Listener Close-Race Probe (repeated short-lived connections)"; flow:to_server; flags:S; threshold: type threshold, track by_src, count 50, seconds 10; classtype:attempted-dos; sid:9830001; rev:1; metadata:reference cve,CVE-2026-98300;)

Elastic Detection

sequence by source.ip with maxspan=10s
  [ network where network.transport == "tcp" and tcp.flags == "S" ]
  [ network where network.transport == "tcp" and tcp.flags == "F" ]

Splunk SPL Query

index=linux sourcetype=syslog OR sourcetype=kernel
("inet_sock_destruct" OR "sk_forward_alloc" OR "tcp_v6_do_rcv" OR "af_inet.c:162")
| stats count values(_raw) as messages by host
| where count > 0

Wazuh OSSEC Rule

<group name="linux,kernel,vulnerability,">
  <rule id="983001" level="12">
    <decoded_as>syslog</decoded_as>
    <match>inet_sock_destruct</match>
    <description>CVE-2026-98300: kernel WARN in inet_sock_destruct (sk_forward_alloc imbalance)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_98300,</group>
  </rule>
  <rule id="983002" level="10">
    <decoded_as>syslog</decoded_as>
    <match>sk_forward_alloc</match>
    <description>CVE-2026-98300: possible TCP IPv6 receive-path forward-alloc accounting inconsistency</description>
    <group>cve_2026_98300,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence was returned by any tracked source, and the NVD description, while referencing an upstream fix, does not supply the commit SHA, release version, or backport identifiers. Treat all affected kernels as unpatched until the distro/vendor advisory is published and verified.

1. Immediate mitigations (no patch available):

• Disable IPv6 on hosts that do not require it, using the standard kernel sysctl controls (net.ipv6.conf.all.disable_ipv6=1 and the per-interface equivalent). This removes the documented trigger path (IPv6 TCP listener receive path) entirely. Record the change in the CMDB — disabling IPv6 can break services that are IPv6-only or have hard-coded AAAA dependencies.
• Where IPv6 must remain enabled, restrict IPv6 TCP listener reachability to trusted source networks using host firewall rules (nftables/iptables with ip6 tables), reducing the attacker's ability to open and close connections at high rate to the vulnerable listener.
• Apply kernel hardening that turns the WARN into a controlled fail instead of a loud splat: tune kernel.panic_on_warn=0 (should already be 0) and do not set it to 1, as that would convert each WARN into a host panic and hand an attacker a trivial DoS. Do not run with panic_on_warn=1 on any host with an IPv6 listener.
• Monitor kernel logs for inet_sock_destruct / sk_forward_alloc warnings and treat any occurrence on an IPv6-listening host as evidence of the race. Rate-limit kernel log forwarding to avoid log-flood self-DoS.
• For high-value hosts, run a kernel built with the upstream fix once it is available from the distro (see below), rather than attempting a runtime mitigation.

2. Patch / upgrade steps:

• No fixed version is currently identified by the tracked sources. When the vendor/distro advisories publish, apply the kernel update through the normal channel (dnf upgrade kernel / apt upgrade linux-image-* / equivalent) and reboot, since the fix is in the IP receive path and cannot be applied live by kpatch-style livepatching until the vendor ships it.
• After upgrading, confirm the running kernel matches the fixed build (uname -r) and re-scan with the detection rules above to confirm the inet_sock_destruct WARN no longer fires under load.
• Track the upstream fix commit once assigned; the fix described in the NVD entry adds a TCP_CLOSE check alongside the existing TCP_LISTEN guard so skb_clone_and_charge_r() is not called locklessly in the close window. Backport verification should confirm this specific guard is present in the running kernel source.

3. Long-term hardening:

• Keep kernel builds current with the distro stable kernel and enable them to be automatically installed; this class of bug is fixed on the stable tree and propagated to LTS distributions.
• Standardize on reachability control for all IPv6 listeners (host firewall plus network ACL), so that a future race or accounting bug in the IPv6 receive path is not exposed to the public internet by default.
• Enable kernel WARN/unusual-message collection in your SIEM with host correlation so that the inet_sock_destruct signature is alerted on, not just logged. This is the only reliable real-time signal for this class until the fix is deployed.
• Track kernel CVE feeds (NVD, distro security trackers, CISA KEV) and maintain a per-host kernel-inventory so affected hosts can be enumerated and remediated quickly when the advisory drops.

References

• NVD entry for CVE-2026-98300: https://nvd.nist.gov/vuln/detail/CVE-2026-98300
• Upstream Linux kernel "net: fix data-races around sk->sk_forward_alloc" commit referenced in the CVE description (sha 073d89808c06) — the prior fix that removed the TCP_LISTEN clone; the follow-up TCP_CLOSE fix is not yet identified in the supplied data
• Linux kernel mailing list / netdev discussion of the fix (search tcp_v6_do_rcv skb_clone_and_charge_r TCP_CLOSE inet_sock_destruct) — highest-value primary source; not provided in the supplied data, verify before citing
• Linux kernel TCP socket memory-accounting documentation (sk_forward_alloc) in Documentation/networking/ and the socket accounting code under net/ipv4/ — background only
• CISA Known Exploited Vulnerabilities catalog: not listed (CISA KEV: NO). No threat-actor campaign or exploit-in-the-wild evidence is associated with CVE-2026-98300 in the supplied data.