Cloudanix VulnDB

CVE-2026-99247

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel startup problem can make the whole system crash if tracing runs into memory trouble very early in the boot process.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

If trace buffer allocation fails during early_trace_init(), tracing_disabled remains set and the global trace array events list is uninitialized; tracer_init_tracefs() then queues tracerfs_init_work without checking the flag, so tracer_init_tracefs_work_func() unconditionally calls event_trace_init() and init_tracer_tracefs(), resulting in __find_event_file() dereferencing the uninitialized list and a NULL pointer dereference kernel oops.

Why it matters to the business

Systems may experience boot-time crashes or instability on kernels where early memory allocation for tracing fails, leading to unplanned downtime and requiring manual intervention to recover.

How an attack unfolds

The condition occurs automatically during boot when allocation fails; no remote attacker action or specific input is required to trigger the dereference, and the flaw has not been observed in active exploitation campaigns.

How to fix it

Apply a kernel update containing the added tracing_disabled check at the start of tracer_init_tracefs_work_func(); rebuild and reboot with the patched kernel image.

How to confirm the fix worked

Inspect the tracer_init_tracefs_work_func() implementation to confirm an early return when tracing_disabled is set; perform boot tests that deliberately fail trace buffer allocation and verify no oops occurs.

Typical attack path

  1. Cause early boot trace buffer allocation to fail (non-attacker-controlled condition)
  2. Allow kernel to reach fs_initcall for tracer_init_tracefs()
  3. Execute queued work item without disabled check
  4. Trigger NULL dereference in __find_event_file()

How to detect it

Examine kernel ring buffer and dmesg output around boot for BUG: Kernel NULL pointer dereference mentioning __find_event_file, init_tracer_tracefs, or tracer_init_tracefs_work_func.

What your security team should do

  • Prioritize kernel updates on all Linux systems once available
  • Review boot logs for tracing-related NULL dereference oopses
  • Test boot resilience under low-memory early-boot scenarios in lab environments

The record

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.

Affected packages

Ecosystem Package Introduced Fixed