Skip to content

CVE-2026-53096

NULL Pointer Dereference: Is CVE-2026-53096 real, exploitable, or a false positive? Here's the community verdict.

signals

public sources

Exploited in wild
Not listed
CISA KEV
Public exploit
None known
Metasploit/EDB/PoC
Base severity
7.8 High
CVSS
Exploitation prob.
0.1%
FIRST EPSS
Weakness
CWE-476 · NULL Pointer Dereference
CWE

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

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 →

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

In the Linux kernel, the following vulnerability has been resolved: bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path The DEVMAP_HASH branch in dev_map_redirect_multi() uses hlist_for_each_entry_safe() to iterate hash buckets, but this function runs under RCU protection (called from xdp_do_generic_redirect_map() in softirq context). Concurrent writers (__dev_map_hash_update_elem, dev_map_hash_delete_elem) modify the list using RCU primitives (hlist_add_head_rcu, hlist_del_rcu). hlist_for_each_entry_safe() performs plain pointer dereferences without rcu_dereference(), missing the acquire barrier needed to pair with writers' rcu_assign_pointer(). On weakly-ordered architectures (ARM64, POWER), a reader can observe a partially-constructed node. It also defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race detection. Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held() as the lockdep condition, consistent with the rcu_dereference_check() used in the DEVMAP (non-hash) branch of the same functions. Also fix the same incorrect lockdep_is_held(&dtab->index_lock) condition in dev_map_enqueue_multi(), where the lock is not held either.

Published

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

Curated baseline: A curated baseline from public sources, shown separately from community verdicts.

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.

  • 0
    Field note · TruePositive EditorialCurated

    This scores high on paper (CVSS 7.8) but the real-world signal is low. It is not in CISA KEV and no public exploit was found, and near-term exploitation looks unlikely (EPSS about 0%). Verify your own exposure before treating it as urgent. It needs local access, so it reads more as a privilege-escalation or post-access risk than a remote one. Not an emergency for most teams, but patch it in your normal cycle and check whether the affected component is actually exposed in your setup.

Add a field note or remediationoptional
Note type

What are you adding?

Markdown supported · minimum 20 characters.

Same weakness: CWE-476 · NULL Pointer Dereference.