CVE-2026-43331

What it actually does

This is a local denial-of-service flaw in x86_64 Linux kernels built with both CONFIG_KEXEC and CONFIG_KCOV enabled. During kexec, load_segments() changes segment registers and invalidates the GS base used by KCOV for per-CPU coverage data. If subsequent C code remains KCOV-instrumented, calls such as native_gdt_invalidate() can enter a repeated kernel crash loop, resulting in loss of system availability. Confidentiality and integrity are not directly affected.

Why it matters to the business

An attacker or malfunctioning privileged process that can invoke kexec can crash affected systems, causing outages, failed crash-dump workflows, interrupted testing/fuzzing infrastructure, and potential loss of diagnostic data. The practical risk is limited because exploitation requires local privileges and a kernel configuration commonly used for fuzzing or specialized debugging rather than standard production builds. The CVE is not in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so remediation should be prioritized mainly for systems that enable KCOV and kexec.

How an attack unfolds

An attacker first needs local access with sufficient privilege to load and execute a new kernel through kexec, typically root or a process with CAP_SYS_BOOT. On an affected x86_64 kernel compiled with CONFIG_KCOV and CONFIG_KEXEC, the attacker loads another kernel image with kexec and triggers execution. During the kexec transition, load_segments() modifies segment registers, invalidating the GS base that KCOV instrumentation expects for per-CPU state. When later KCOV-instrumented kernel code executes, such as native_gdt_invalidate(), the kernel can fault repeatedly or enter an endless crash loop. The result is a local availability impact rather than remote code execution or privilege escalation.

How to fix it

Upgrade to a vendor-supplied Linux kernel that includes the upstream fix disabling KCOV instrumentation for the affected x86 kexec-related code paths, specifically machine_kexec_64.c and physaddr.c. No exact fixed package versions were provided, so use the fixed kernel version published by the relevant Linux distribution or appliance vendor. Where immediate patching is not possible, avoid using KCOV-enabled kernels outside controlled testing, rebuild production kernels without CONFIG_KCOV, and restrict kexec usage to trusted administrators only. If kexec is not operationally required, disable it using platform controls such as kernel.kexec_load_disabled=1 where supported, lockdown/Secure Boot policy, capability restrictions, and strict sudo policy around the kexec utility. Avoid testing kexec reproduction on production systems because successful triggering may crash the host.

How to confirm the fix worked

Confirm whether systems are exposed by checking that they are x86_64 and whether the running kernel configuration enables both CONFIG_KCOV and CONFIG_KEXEC, for example by reviewing /boot/config-$(uname -r), /proc/config.gz, or vendor kernel build metadata. Verify remediation by confirming the installed kernel package includes the vendor fix for this CVE or by checking the patched source/patch notes showing KCOV instrumentation disabled for the relevant x86 kexec files. Confirm runtime mitigation by verifying unauthorized users cannot execute kexec, that kexec-related syscalls are restricted where feasible, and that kernel.kexec_load_disabled is set if kexec is not required. Functional validation should be performed only in a controlled test environment by exercising kexec on the patched kernel and confirming no panic, endless crash loop, or KCOV-related fault occurs.

Typical attack path

1. Obtain local privileged access, root access, or equivalent capability to invoke kexec.
2. Confirm or assume the target is an x86_64 Linux kernel built with both CONFIG_KEXEC and CONFIG_KCOV enabled.
3. Load an alternate kernel image using kexec.
4. Trigger kexec execution.
5. Kernel transition code invalidates GS base while KCOV-instrumented code still executes.
6. The kernel crashes, loops, or becomes unavailable, forcing service interruption or reboot/recovery.

How to detect it

Look for evidence of unexpected kexec use followed by a kernel panic, reboot, hang, or crash loop. Relevant sources include auditd syscall logs for kexec_load and kexec_file_load, process execution logs for the kexec utility, sudo logs, shell history, EDR telemetry, systemd journal entries, kernel ring buffer logs, pstore/ramoops, kdump vmcore analysis, hypervisor console logs, and out-of-band management event logs. In crash artifacts, search for stack traces or messages involving KCOV, sanitizer coverage, __sanitizer_cov_trace_pc(), native_gdt_invalidate(), load_segments(), machine_kexec_64.c, or physaddr.c. Because exploitation causes availability failure, the most reliable evidence may be immediately before reboot or in persistent crash logging. Treat kexec activity as suspicious when it is not part of approved crash-dump, kernel upgrade, fuzzing, or test automation workflows.

• kexec -e
• kexec -l
• kexec_load
• kexec_file_load
• CONFIG_KCOV=y
• CONFIG_KEXEC=y
• __sanitizer_cov_trace_pc
• native_gdt_invalidate
• load_segments
• machine_kexec_64.c
• physaddr.c
• KCOV
• audit:.*kexec_load
• audit:.*kexec_file_load
• COMMAND=/usr/sbin/kexec
• COMMAND=/sbin/kexec
• /proc/sys/kernel/kexec_load_disabled
• /sys/kernel/debug/kcov

What your security team should do

• Inventory Linux systems running x86_64 kernels with CONFIG_KCOV and CONFIG_KEXEC enabled; prioritize these for remediation.
• Patch affected kernels using the appropriate distribution or vendor update as soon as practical, especially on fuzzing, CI, crash-dump, and kernel-testing systems.
• Remove KCOV from production kernel builds unless coverage-guided kernel fuzzing is explicitly required.
• Restrict kexec execution to tightly controlled administrative workflows and review sudoers, capabilities, and automation that can invoke kexec.
• If kexec is not required, disable it with kernel.kexec_load_disabled=1 or equivalent platform hardening controls.
• Monitor audit, shell, EDR, and kernel logs for unexpected kexec usage and for crashes referencing KCOV or sanitizer coverage functions.
• Preserve pstore, kdump, journal, and hypervisor console logs after unexplained reboots to support root-cause analysis.