Skip to content

CVE-2026-43501

Out-of-bounds Write: Is CVE-2026-43501 real, exploitable, or a false positive? Here's the community verdict.

signals

public sources

Exploited in wild
Not listed
CISA KEV
Public exploit
PoC (unverified)
Metasploit/EDB/PoC
Base severity
9.8 Critical
CVSS
Exploitation prob.
0.5%
FIRST EPSS
Weakness
CWE-787 · Out-of-bounds Write
CWE

High CVSS base score, but low real-world exploitation probability (EPSS). Likely less urgent than the score implies.

public exploits

links to sources — we don’t host code

Unverified proof-of-concept code has been published. It may or may not be functional — assess before relying on it.

baseline read

auto · not a community verdict

Real, but low real-world risk

A genuine vulnerability on paper, but EPSS shows little real-world exploitation — the base score may overstate urgency. This is not the same as a false positive.

Based on CVSS · FIRST EPSS

Confirm or dispute →
Affected:Linux

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.

Published

Embed this verdict
TruePositive verdict for CVE-2026-43501
Markdown
[![TruePositive verdict](https://www.truepositive.app/cve/CVE-2026-43501/badge.svg)](https://www.truepositive.app/cve/CVE-2026-43501)
HTML
<a href="https://www.truepositive.app/cve/CVE-2026-43501"><img src="https://www.truepositive.app/cve/CVE-2026-43501/badge.svg" alt="TruePositive verdict for CVE-2026-43501"></a>

Live badge that updates automatically as the community verdict changes.

Community ground truth

Be the first practitioner to weigh in

So far this is only TruePositive's editorial baseline from public sources. Add your real-world verdict below — it becomes the signal the next person triaging this relies on.

🥇 The first 50 practitioners to contribute earn a Founding Contributor badge.

In your experience, is this finding real and exploitable?

awaiting field verdicts
Real, but not a risk here
Not a real issue

No account needed. Anonymous verdicts post as an unverified signal. Log in to make yours verified and earn reputation.

Field notes & remediation

Verdicts are the quick signal. Notes are the evidence and fixes behind them.

No notes yet. Be the first to share what you saw, or a fix that worked.

    Add a field note or remediationoptional
    Note type

    What are you adding?

    Markdown supported · minimum 20 characters.

    Same weakness: CWE-787 · Out-of-bounds Write.