CVE-2026-97933

UNRATEDCVSS · not yet scoredTrending — 6 sources updated this week
—
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0.2%CVSS v2: —Exploit: 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:

tracing: Take trace_array reference when opening a tracer options file

When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened.

Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed.

To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased.

Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done.

CVSS v3
—
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
—
EG Risk
—
EPSS PROB
0.2%
EPSS %ILE
8th
KEV
Not listed

Published

September 25, 2026

Last Modified

October 3, 2026

Vendor Advisories for CVE-2026-97933(2)

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
linux6.1.106-1 ... 7.2~rc7-1~exp1 (360 versions)
  • every version on: no fix on record
—
Debian:13(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 7.2~rc7-1~exp1 (183 versions)
  • every version on: no fix on record
—
Debian:14(1)
PackageVulnerable rangeFix by version rangeDependents
linux6.12.100-1 ... 7.2~rc7-1~exp1 (180 versions)
  • every version up to 7.2.7-1: fixed in 7.2.7-1
—

Data Freshness Timeline

(refreshed 17× in last 7d / 22× 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-04 23:23 UTCEPSS rescore
  2. 2026-10-03 14:26 UTCEPSS rescore
  3. 2026-10-03 11:26 UTCNVD update
  4. 2026-10-03 11:18 UTCVendor advisory
  5. 2026-10-03 11:17 UTCGHSA enrichment
  6. 2026-10-03 11:10 UTCMITRE cvelistV5
  7. 2026-10-02 17:57 UTCEPSS rescore
  8. 2026-10-01 19:51 UTCEPSS rescore
  9. 2026-10-01 10:54 UTCEG score recompute
  10. 2026-10-01 10:54 UTCVendor advisory
  11. 2026-10-01 10:54 UTCGHSA enrichment
  12. 2026-09-30 15:04 UTCEPSS rescore
  13. 2026-09-28 13:52 UTCEPSS rescore
  14. 2026-09-28 13:52 UTCEPSS rescore
  15. 2026-09-28 11:15 UTCEG score recompute
  16. 2026-09-28 11:15 UTCVendor advisory
  17. 2026-09-28 11:15 UTCGHSA enrichment
  18. 2026-09-27 13:49 UTCEPSS rescore
  19. 2026-09-26 15:59 UTCEPSS rescore
  20. 2026-09-25 11:30 UTCNVD update
  21. 2026-09-25 10:35 UTCEG score recompute
  22. 2026-09-25 10:27 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-97933?
CVE-2026-97933 is a publicly disclosed vulnerability published on September 25, 2026. In the Linux kernel, the following vulnerability has been resolved: tracing: Take trace_array reference when opening a tracer options file When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find…
When was CVE-2026-97933 disclosed?
CVE-2026-97933 was first published on September 25, 2026, with the most recent update on October 3, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-97933 actively exploited?
CVE-2026-97933 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.2% probability of exploitation in the next 30 days (8th percentile of EPSS-scored CVEs).
How do I remediate CVE-2026-97933?
No fix for CVE-2026-97933 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-97933 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-97933

Explore →

Is Your Infrastructure Affected by CVE-2026-97933?

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