CVE-2026-90001

HIGHPre-NVD 7.87.8—
EchelonGraph scoreHIGH confidence

Score 7.8 from GitHub Security Advisory (severity: HIGH) published 2026-09-16. A secondary CVSS source baseline 7.8; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 3 sources updated this week
7.8EG
EchelonGraph verdictPlan mitigationSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0.2%CVSS: 7.8Exploit: None knownExposed services: Not assessed

No fix is confirmed yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for the fix.

In the Linux kernel, the following vulnerability has been resolved:

HID: bpf: serialize device reference release in struct_ops destroy path

__hid_bpf_ops_destroy_device() and hid_bpf_unreg() can race on the same registration reference, double-putting struct hid_device and freeing it while hid_destroy_device() still uses it. Serialize the remove/NULL decision under hdev->bpf.prog_list_lock so exactly one path releases each registration reference: unreg re-checks ops->hdev under the lock and returns without putting when the destroy path already cleared it; all put_device() calls happen after the lock is dropped, which is safe because a concurrent unreg then observes ops->hdev == NULL under the lock.

Background: each successful attach (hid_bpf_ops_reg) acquires one device reference (hid_get_device()). Two paths can release it:

  • device destruction: hid_destroy_device() -> hid_bpf_destroy_device()
-> __hid_bpf_ops_destroy_device(), which walks hdev->bpf.prog_list under rcu_read_lock() and drops one reference per attached program;
  • BPF link release: bpf map delete (no BPF_F_LINK) synchronously calls
st_ops->unreg() -> hid_bpf_unreg(), which drops the reference for its own registration.

The coordination handshake (e->hdev = NULL on the destroy side vs "if (!hdev) return" on the unreg side) is a TOCTOU check: the two paths run under different lock domains (rcu_read_lock vs prog_list_lock), so a concurrent unreg can read ops->hdev as non-NULL, block on prog_list_lock, and then proceed while the destroy traversal executes - both paths then drop the same reference. The refcount reaches zero legitimately (each decrement is individually valid), so no refcount_t saturation fires: the device is simply freed while the transport is still inside hid_destroy_device(), and subsequent teardown touches freed memory.

The fix serializes the remove/NULL decision under prog_list_lock on both sides and moves the destroy-side puts outside the lock. With the lock held, plain reads/writes of ops->hdev are sufficient; no READ_ONCE/WRITE_ONCE are added, keeping the patch minimal.

Unlocked-read safety: the unlocked read of ops->hdev at the top of hid_bpf_unreg() cannot touch a freed device, because the unreg path itself still holds this registration's reference (released only by its own hid_put_device() after the lock is dropped), and a destroy traversal that already cleared ops->hdev makes the lock-internal re-check return early without any put. At most one of the two paths releases each registration reference.

CVSS v3
7.8
EG Score
7.8HIGHhigh confidence
EG Risk
40
EG Risk 40/100CISA SSVC

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity78% × 45%
Exploitation0% × 40%
Automatability30% × 15%
CISA SSVC: Track at low or medium mission impact; Track or Attend at high (mission-essential systems).
Action: No fix is confirmed yet. Restrict network exposure of the affected system or apply the vendor's mitigation within your standard update timelines at low or medium mission impact and sooner than that at high, and watch the vendor's advisory for the fix.
EPSS PROB
0.2%
EPSS %ILE
6th
KEV
Not listed

CISA SSVCTrack at low or medium mission impact; Track or Attend at high (mission-essential systems).

No fix is confirmed yet. Restrict network exposure of the affected system or apply the vendor's mitigation within your standard update timelines at low or medium mission impact and sooner than that at high, and watch the vendor's advisory for the fix.

Exploitation none (no KEV listing, exploit record or EPSS ≥ 50%) · Automatable unknown (not published for this CVE) · Technical impact partial (CVSS below 9.0). Mission impact is CISA's Mission & Well-being decision point, and only you can judge it: high means the affected system is essential to your organisation's mission, or its compromise could cause irreversible harm to people. CISA's decision table

Published

September 16, 2026

Last Modified

September 16, 2026

Advisory Details (4)

Auto-updated Sep 16, 2026
No patch confirmed yet.
generic

HID: bpf: serialize device reference release in struct_ops destroy path - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/c7f927aa8b55008ed5ea0814313d5dad771dcf3c
generic

HID: bpf: serialize device reference release in struct_ops destroy path - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/bfb7939788f3c8dd080a4dd81e38d625b35d194e
generic

HID: bpf: serialize device reference release in struct_ops destroy path - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/9cdc7e6dc7a99ad7311ad5e7c145f2b9ce4e24b0
generic

HID: bpf: serialize device reference release in struct_ops destroy path - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/401359684620145be710de97b87e1a47abfe1459

Vendor Advisories for CVE-2026-90001(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(3 across 3 ecosystems)
Debian:12(1)
PackageVulnerable rangeFix by version rangeDependents
linux-6.126.12.100-1~deb12u1, 6.12.101-1~deb12u1, 6.12.107-1~deb12u1
  • every version up to 6.12.111-1~deb12u1: fixed in 6.12.111-1~deb12u1
—
Debian:13(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 6.12.96-1 (35 versions)
  • every version up to 6.12.111-1: fixed in 6.12.111-1
—
Debian:14(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 7.2~rc7-1~exp1 (179 versions)
  • every version up to 7.2.6-1: fixed in 7.2.6-1
—

Data Freshness Timeline

(refreshed 27× in last 7d / 80× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-10-05 05:07 UTCEG score recompute
  2. 2026-10-05 05:07 UTCGHSA enrichment
  3. 2026-10-04 23:22 UTCEPSS rescore
  4. 2026-10-04 17:24 UTCGHSA enrichment
  5. 2026-10-04 05:40 UTCGHSA enrichment
  6. 2026-10-03 17:58 UTCEG score recompute
  7. 2026-10-03 17:58 UTCGHSA enrichment
  8. 2026-10-03 06:12 UTCGHSA enrichment
  9. 2026-10-02 18:29 UTCEG score recompute
  10. 2026-10-02 18:29 UTCGHSA enrichment
  11. 2026-10-02 06:47 UTCEG score recompute
  12. 2026-10-02 06:47 UTCGHSA enrichment
  13. 2026-10-01 19:51 UTCEPSS rescore
  14. 2026-10-01 19:05 UTCGHSA enrichment
  15. 2026-10-01 07:23 UTCGHSA enrichment
  16. 2026-09-30 19:41 UTCEG score recompute
  17. 2026-09-30 19:41 UTCGHSA enrichment
  18. 2026-09-30 15:04 UTCEPSS rescore
  19. 2026-09-30 07:59 UTCGHSA enrichment
  20. 2026-09-29 20:17 UTCEG score recompute
  21. 2026-09-29 20:17 UTCGHSA enrichment
  22. 2026-09-29 08:34 UTCEG score recompute
  23. 2026-09-29 08:34 UTCGHSA enrichment
  24. 2026-09-28 20:52 UTCEG score recompute
  25. 2026-09-28 20:52 UTCGHSA enrichment
Show 55 more
  1. 2026-09-28 13:52 UTCEPSS rescore
  2. 2026-09-28 13:52 UTCEPSS rescore
  3. 2026-09-28 09:10 UTCGHSA enrichment
  4. 2026-09-27 21:28 UTCEG score recompute
  5. 2026-09-27 21:27 UTCGHSA enrichment
  6. 2026-09-27 13:49 UTCEPSS rescore
  7. 2026-09-27 09:44 UTCGHSA enrichment
  8. 2026-09-26 22:02 UTCEG score recompute
  9. 2026-09-26 22:02 UTCGHSA enrichment
  10. 2026-09-26 15:59 UTCEPSS rescore
  11. 2026-09-26 10:20 UTCEG score recompute
  12. 2026-09-26 10:20 UTCGHSA enrichment
  13. 2026-09-25 22:34 UTCGHSA enrichment
  14. 2026-09-25 10:49 UTCGHSA enrichment
  15. 2026-09-24 23:01 UTCEG score recompute
  16. 2026-09-24 23:01 UTCGHSA enrichment
  17. 2026-09-24 14:04 UTCEPSS rescore
  18. 2026-09-24 10:53 UTCGHSA enrichment
  19. 2026-09-23 23:10 UTCEG score recompute
  20. 2026-09-23 23:10 UTCGHSA enrichment
  21. 2026-09-23 17:54 UTCEPSS rescore
  22. 2026-09-23 11:20 UTCGHSA enrichment
  23. 2026-09-22 23:38 UTCEG score recompute
  24. 2026-09-22 23:38 UTCGHSA enrichment
  25. 2026-09-22 16:01 UTCEPSS rescore
  26. 2026-09-22 11:55 UTCGHSA enrichment
  27. 2026-09-22 00:13 UTCEG score recompute
  28. 2026-09-22 00:13 UTCGHSA enrichment
  29. 2026-09-21 21:09 UTCEPSS rescore
  30. 2026-09-21 12:31 UTCGHSA enrichment
  31. 2026-09-21 00:49 UTCEG score recompute
  32. 2026-09-21 00:49 UTCGHSA enrichment
  33. 2026-09-20 20:16 UTCEPSS rescore
  34. 2026-09-20 13:07 UTCGHSA enrichment
  35. 2026-09-20 01:21 UTCEG score recompute
  36. 2026-09-20 01:21 UTCGHSA enrichment
  37. 2026-09-19 13:39 UTCGHSA enrichment
  38. 2026-09-19 01:57 UTCEG score recompute
  39. 2026-09-19 01:57 UTCGHSA enrichment
  40. 2026-09-18 19:28 UTCEPSS rescore
  41. 2026-09-18 14:15 UTCGHSA enrichment
  42. 2026-09-18 02:30 UTCEG score recompute
  43. 2026-09-18 02:30 UTCGHSA enrichment
  44. 2026-09-17 19:32 UTCEPSS rescore
  45. 2026-09-17 14:47 UTCGHSA enrichment
  46. 2026-09-17 03:05 UTCEG score recompute
  47. 2026-09-17 03:05 UTCGHSA enrichment
  48. 2026-09-16 15:22 UTCEG score recompute
  49. 2026-09-16 15:22 UTCGHSA enrichment
  50. 2026-09-16 14:47 UTCEG score recompute▲ 7.80
  51. 2026-09-16 14:47 UTCGHSA enrichment
  52. 2026-09-16 14:45 UTCMITRE cvelistV5CVSS v3 → 7.8 · severity → HIGH
  53. 2026-09-16 11:21 UTCNVD update
  54. 2026-09-16 10:38 UTCEG score recompute
  55. 2026-09-16 10:36 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-90001?
CVE-2026-90001 is a high vulnerability published on September 16, 2026. In the Linux kernel, the following vulnerability has been resolved: HID: bpf: serialize device reference release in struct_ops destroy path hidbpfopsdestroydevice() and hidbpfunreg() can race on the same registration reference, double-putting struct hid_device and freeing it while…
When was CVE-2026-90001 disclosed?
CVE-2026-90001 was first published on September 16, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-90001 actively exploited?
CVE-2026-90001 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.2% probability of exploitation in the next 30 days (6th percentile of EPSS-scored CVEs).
What is the CVSS score of CVE-2026-90001?
CVE-2026-90001 has a CVSS base score of 7.8 (a secondary CVSS source that NVD displays; NVD's own analysis pending).
How do I remediate CVE-2026-90001?
No fix for CVE-2026-90001 is confirmed yet. Until one is published, restrict network exposure of the affected system or apply the vendor's mitigation — for example, keep it off the internet or limit it to trusted networks — and watch the vendor's advisory for the fix. The vendor advisories EchelonGraph has for CVE-2026-90001 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2026-90001

Explore →

Is Your Infrastructure Affected by CVE-2026-90001?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.