Skip to main content
← Vulnerabilities

tracing: Do not initialize tracefs work if tracing is disabled

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

—Not rated
Exploited
No known exploitation
Fix
No fix listed
Who is exposed
Not reported
25Pcve.now Index 25 of 100 · methodology v3 · provisional
  • Exploitation?/40Exploitation: unknown (data gap). No CISA SSVC exploitation rating yet
  • Exposure?/25Exposure: unknown (data gap). No advisory context yet
  • Reach20/20Affects Linux kernel (software on nearly every server, desktop or phone)
  • Severity?/10Severity: unknown (data gap). No CVSS score or vendor rating
  • No patch5/5No patch listed yet

What would change the score

  • Would score about 80 if added to CISA KEV
  • Would score about 75 if CISA's SSVC rates exploitation active
  • Would score about 47 if advisories confirm default setups are exposed

CVE-2026-99247 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It affects Linux; no fixed version is listed yet.

Published
Last modified
Published
Not listed in CISA KEV
25/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

The Linux kernel's tracing subsystem (tracefs) is affected when trace buffer allocation fails during early boot. In that case, tracing is left disabled but its deferred initialization still runs, which can cause a NULL pointer dereference and a kernel crash (Oops) during boot.

Read the original description

In the Linux kernel, the following vulnerability has been resolved: tracing: Do not initialize tracefs work if tracing is disabled If trace buffer allocation fails during early boot (e.g. in early_trace_init() -> allocate_trace_buffers()), tracing_disabled is left set to 1 and the global trace array events list remains uninitialized. Later during boot, tracer_init_tracefs() (invoked via fs_initcall) queues tracerfs_init_work asynchronously without checking if tracing was disabled. When tracer_init_tracefs_work_func() runs, it calls event_trace_init() and init_tracer_tracefs(&global_trace, NULL) unconditionally. This leads to __find_event_file() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops: BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] __find_event_file+0x70/0x3c0 LR [c000000000448874] init_tracer_tracefs+0x274/0xc80 Call Trace: init_tracer_tracefs+0x274/0xc80 tracer_init_tracefs_work_func+0x50/0x320 process_one_work+0x1e8/0x5c0 worker_thread+0x1dc/0x3d0 kthread+0x194/0x1b0 start_kernel_thread+0x14/0x18 Check tracing_disabled at the beginning of tracer_init_tracefs_work_func() and return immediately if tracing is disabled or failed to initialize, preventing the crash.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    5.19

Evidence 6

  1. Link
  2. Link
  3. Link
  4. Link
  5. Link
  6. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

Questions about CVE-2026-99247

Is CVE-2026-99247 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

Which versions are affected by CVE-2026-99247?

Linux: version 5.19.Source: cve.now feed data