CVE-2026-43331: Linux Kernel DOS Vulnerability

CVE-2026-43331 Overview

CVE-2026-43331 is a Linux kernel vulnerability in the x86/kexec subsystem. The load_segments() function modifies segment registers, invalidating the GS base that Kernel Coverage (KCOV) relies on for per-CPU data access. When CONFIG_KCOV is enabled, subsequent instrumented C code calls such as native_gdt_invalidate() trigger an endless crash loop. The flaw affects Linux kernel 7.0 release candidates and is exercised by workflows that combine CONFIG_KEXEC and CONFIG_KCOV, such as syzkaller crash dump collection during coverage-guided fuzzing. The issue does not affect 32-bit kernels because KCOV is unsupported on that architecture.

Critical Impact

A local user with kexec privileges can trigger a kernel crash loop on KCOV-instrumented x86_64 systems, resulting in denial of service.

Affected Products

• Linux Kernel 7.0-rc1 through 7.0-rc6
• x86_64 kernels built with CONFIG_KCOV and CONFIG_KEXEC enabled
• Systems running coverage-guided fuzzing tooling such as syzkaller

Discovery Timeline

• 2026-05-08 - CVE-2026-43331 published to NVD
• 2026-05-18 - Last updated in NVD database

Technical Details for CVE-2026-43331

Vulnerability Analysis

The vulnerability resides in arch/x86/kernel/machine_kexec_64.c. During a kexec operation, load_segments() reloads the segment registers in preparation for transitioning to a new kernel. This operation invalidates the GS base register on x86_64.

KCOV is the kernel's coverage instrumentation infrastructure used by fuzzers such as syzkaller. KCOV stores per-CPU coverage state accessed through the GS base. Every function compiled with KCOV instrumentation contains a call to __sanitizer_cov_trace_pc() at each basic block. This callback dereferences per-CPU data via GS.

After load_segments() executes, the GS base no longer points to valid per-CPU data. The next instrumented function call, including native_gdt_invalidate(), attempts to record coverage and faults. The fault handler itself is instrumented, producing a recursive crash loop that hangs the kernel.

Root Cause

The root cause is a mismatch between the late-stage kexec teardown sequence and the assumptions made by KCOV instrumentation. KCOV expects a valid GS base throughout kernel execution. The kexec code path violates this invariant before instrumented C functions are invoked.

Attack Vector

Exploitation requires local access with privileges sufficient to invoke kexec. An attacker with CAP_SYS_BOOT can load a secondary kernel and trigger the transition. On affected builds, this reliably crashes the running kernel and denies service. The reproduction sequence is kexec -l /boot/otherKernel followed by kexec -e.

The issue is not a memory corruption primitive and does not yield code execution or information disclosure. The CWE classification is recorded as NVD-CWE-noinfo.

No public proof-of-concept beyond the upstream reproducer has been released, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

Detection Methods for CVE-2026-43331

Indicators of Compromise

• Unexplained kernel hangs or panic loops immediately following a kexec -e invocation on x86_64 hosts.
• Crash signatures referencing native_gdt_invalidate() or __sanitizer_cov_trace_pc() in serial console output.
• Presence of both CONFIG_KCOV=y and CONFIG_KEXEC=y on kernel build configurations in production environments.

Detection Strategies

• Audit kernel build configurations across the fleet to identify systems where KCOV instrumentation is enabled outside dedicated fuzzing infrastructure.
• Monitor for kexec_load and kexec_file_load syscalls in audit logs to identify users invoking kexec on sensitive hosts.
• Alert on kernel panics correlated with prior kexec activity from non-administrative accounts.

Monitoring Recommendations

• Enable auditd rules for CAP_SYS_BOOT capability use and kexec-related syscalls.
• Forward kernel ring buffer messages and panic traces to a centralized logging platform for retrospective analysis.
• Track the running kernel version on all x86_64 hosts and flag any system still on Linux 7.0-rc1 through 7.0-rc6 with KCOV enabled.

How to Mitigate CVE-2026-43331

Immediate Actions Required

• Upgrade affected x86_64 hosts to a Linux kernel build that includes the upstream fix referenced in the kernel.org commits.
• Remove CONFIG_KCOV from production kernel configurations; KCOV is intended for fuzzing and development environments only.
• Restrict the CAP_SYS_BOOT capability to a minimal set of administrative accounts and review sudo policies that permit kexec.

Patch Information

The fix disables KCOV instrumentation for the entire arch/x86/kernel/machine_kexec_64.c and arch/x86/mm/physaddr.c translation units. This approach was chosen over per-function annotations because the latter is fragile and over guarding the KCOV fast path because that would impose runtime overhead on every instrumented call. The upstream patches are available as Kernel Git Commit 1e3e985, Kernel Git Commit 917e3ad, and Kernel Git Commit de05c66.

Workarounds

• Disable CONFIG_KCOV and rebuild the kernel where coverage instrumentation is not required.
• Avoid invoking kexec on KCOV-instrumented kernels until the patched build is deployed.
• For syzkaller crash-dump workflows, pin fuzzing hosts to patched kernel revisions before re-enabling combined CONFIG_KEXEC and CONFIG_KCOV builds.

# Verify whether the running kernel was built with KCOV instrumentation
grep -E 'CONFIG_KCOV|CONFIG_KEXEC' /boot/config-$(uname -r)

# Restrict kexec capability to root only and audit invocations
auditctl -a always,exit -F arch=b64 -S kexec_load -S kexec_file_load -k kexec_use