AZL-112601: CVE-2026-99247 affecting package kernel 6.6.159.1-1
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 earlytraceinit() -> allocatetracebuffers()), tracingdisabled is left set to 1 and the global trace array events list remains uninitialized.
Later during boot, tracerinittracefs() (invoked via fsinitcall) queues tracerfsinitwork asynchronously without checking if tracing was disabled. When tracerinittracefsworkfunc() runs, it calls eventtraceinit() and inittracertracefs(&globaltrace, NULL) unconditionally. This leads to findeventfile() 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] findeventfile+0x70/0x3c0 LR [c000000000448874] inittracertracefs+0x274/0xc80 Call Trace: inittracertracefs+0x274/0xc80 tracerinittracefsworkfunc+0x50/0x320 processonework+0x1e8/0x5c0 workerthread+0x1dc/0x3d0 kthread+0x194/0x1b0 startkernelthread+0x14/0x18
Check tracingdisabled at the beginning of tracerinittracefsworkfunc() and return immediately if tracing is disabled or failed to initialize, preventing the crash.
Affected Software
Event History
Frequently Asked Questions
What log evidence indicates that this failure has occurred?
Look for an early-boot kernel NULL pointer dereference/Oops involving __find_event_file, with init_tracer_tracefs and tracer_init_tracefs_work_func in the call trace. The reported fault is a read at address 0x00000010.
Is normal tracefs initialization by itself sufficient to trigger the failure?
No. The reported sequence requires trace buffer allocation to fail during early boot, leaving tracing disabled and the global trace event list uninitialized before asynchronous tracefs initialization runs.