CVE-2026-99247 in Linux
Summary
by MITRE • 11/03/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The Linux kernel contains a critical initialization flaw within its dynamic tracing subsystem that can lead to a system panic during early boot phases. This vulnerability arises from an inconsistency in how the state of the tracing infrastructure is managed when trace buffer allocation fails. Specifically, if the function allocate_trace_buffers() encounters an error and returns failure, the global variable tracing_disabled is correctly set to one, indicating that tracing should not proceed. However, this flag does not prevent subsequent initialization routines from attempting to interact with uninitialized data structures associated with the tracer subsystem. The core issue lies in the asynchronous work queue mechanism used to initialize tracefs entries, which operates independently of the early boot failure state and fails to validate whether tracing was successfully enabled before accessing kernel memory.
The technical root cause is located in the interaction between fs_initcall routines and deferred work processing. During system startup, tracer_init_tracefs() schedules a work item via fs_initcall without verifying if tracing has been disabled due to prior allocation failures. When this scheduled work eventually executes through tracer_init_tracefs_work_func(), it proceeds unconditionally to call event_trace_init() and init_tracer_tracefs(). These functions assume that the global trace array events list is properly initialized. Because the initial buffer allocation failed, this list remains uninitialized or null. Consequently, when __find_event_file() attempts to dereference pointers within this non-existent list, a NULL pointer dereference occurs. This results in an Oops condition with a kernel access of bad area error, effectively crashing the operating system before it can fully boot and become operational for users.
From a security and reliability perspective, this vulnerability represents a significant availability risk as it prevents the Linux kernel from completing its startup sequence on affected systems where trace buffer allocation is constrained or fails due to resource limits or memory fragmentation. The incident aligns with CWE-476, which describes NULL Pointer Dereference vulnerabilities, specifically occurring in system-level code during initialization sequences. Furthermore, this flaw can be contextualized within the ATT&CK framework under techniques related to impact and disruption of services, as a successful exploit allows an attacker who controls early boot conditions or memory allocation patterns to cause a denial of service by triggering the kernel panic. The lack of state validation before accessing shared data structures highlights a gap in defensive coding practices for asynchronous initialization tasks within the kernel core.
To mitigate this vulnerability, developers must ensure that all deferred work items related to tracing subsystems explicitly check the global tracing_disabled flag at their entry point. If tracing is found to be disabled or if prior initialization steps have failed, the work function should return immediately without attempting to access any trace-related data structures such as the events list. This simple conditional guard prevents the execution of code paths that rely on initialized state, thereby avoiding the NULL pointer dereference. System administrators and developers relying on stable kernel builds should ensure they are running patched versions of the Linux kernel where this logic has been corrected in tracer_init_tracefs_work_func(). Regular updates to the kernel base are essential as early boot vulnerabilities can have severe consequences for system integrity and availability.