Cloudanix VulnDB

CVE-2026-99093

None

CVSS

—

EPSS

0.2%

Published

Oct 26, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the core operating system can crash the machine during startup if certain debugging features are turned on in the boot settings.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Kernel panic occurs during early boot when a function tracer with specific filters triggers page table splitting and immediate collapse, attempting to queue deferred freeing work on a NULL percpu workqueue that has not yet been initialized.

Why it matters to the business

Systems configured with boot-time function tracing may fail to start, causing operational downtime and requiring configuration changes or kernel updates to restore availability.

How an attack unfolds

An attacker with the ability to control kernel boot parameters sets a function tracer filter targeting page table freeing routines; this reaches the uninitialized workqueue path during trampoline setup, resulting in a general protection fault and kernel panic.

How to fix it

Apply the upstream fix that skips workqueue scheduling for deferred kernel page table freeing while the system is still booting; rebuild and deploy the patched kernel.

How to confirm the fix worked

Boot the updated kernel with the same ftrace=function and ftrace_filter settings that previously triggered the panic and confirm the system reaches a stable state without oops or kernel panic messages referencing __queue_work or pagetable_free_kernel.

Typical attack path

  1. Modify bootloader configuration to enable function tracing with a targeted filter
  2. Initiate system boot
  3. Tracer starts before workqueue initialization
  4. Page table operations attempt deferred free via queue_work_on
  5. NULL workqueue dereference triggers fault and panic

How to detect it

Review kernel boot logs and dmesg for general protection faults, null pointer dereferences in __queue_work, or panics mentioning pagetable_free_kernel and swapper task; check for unexpected early boot failures on systems with ftrace enabled.

What your security team should do

  • Prioritize patching kernel images used in environments that rely on early boot tracing
  • Audit bootloader configurations for ftrace parameters across fleets
  • Add boot-time tracer configurations to regression test suites
  • Monitor for similar early-init race conditions in future kernel releases

The record

In the Linux kernel, the following vulnerability has been resolved: mm: don't schedule deferred kernel page table freeing while booting Booting with a boot-time function tracer and a filter, for example ftrace=function ftrace_filter=pud_free_pmd_page panics on 7.3-rc4 as soon as the tracer starts: [ 23.531178] Starting tracer 'function' [ 23.675800] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN NOPTI [ 23.819917] KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] [ 23.964025] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.3.0-rc4-fe2ec83746e5-with-fixes-v2+ #195 PREEMPT(undef) [ 24.252248] RIP: 0010:__queue_work+0xab/0xf00 [ 25.981629] Call Trace: [ 26.125727] <TASK> [ 26.413912] ? pagetable_free_kernel+0x20/0x120 [ 26.990283] queue_work_on+0x97/0xf0 [ 27.134382] __cpa_collapse_large_pages+0x501/0x6f0 [ 27.566662] cpa_flush+0x394/0x620 [ 27.998953] change_page_attr_set_clr+0x321/0x4a0 [ 29.151729] set_memory_rox+0xa2/0xf0 [ 29.584018] create_trampoline+0x431/0x6f0 ... [ 44.343347] Kernel panic - not syncing: Attempted to kill the idle task! The boot-time tracer is started from early_trace_init(), which runs before workqueue_init_early(). Making its trampoline read-only splits a large page, and CPA collapses it again right away. The split table has been a kernel page table since commit 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables"), so the collapse frees it through pagetable_free_kernel(), which queues work on system_percpu_wq - still NULL at that point. That commit is correct in itself; it only lets CPA reach pagetable_free_kernel() before the workqueue that function relies on exists. Keep putting the table on the list, but don't schedule the work while the system is still booting. A core_initcall schedules it once to free whatever was queued by then.

Affected packages

Ecosystem Package Introduced Fixed