Skip to main content

Linux Kernel CVE-2026-43331

| EUVDEUVD-2026-28615 MEDIUM
2026-05-08 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-9w3c-wc93-j4jx
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 18, 2026 - 12:53 vuln.today
CVSS changed
May 18, 2026 - 12:52 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 15:02 EUVD
CVE Published
May 08, 2026 - 14:16 nvd
UNKNOWN (no severity yet)

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

x86/kexec: Disable KCOV instrumentation after load_segments()

The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop.

To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel:

$ kexec -l /boot/otherKernel $ kexec -e

The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously.

Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead.

Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered.

The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there.

[ bp: Space out comment for better readability. ]

AnalysisAI

Kernel crash loop in x86_64 Linux when kexec is executed on a kernel built with both CONFIG_KCOV and CONFIG_KEXEC enabled. The load_segments() function invalidates the GS base register that KCOV relies on for per-cpu data access; any subsequently instrumented C function call (e.g. native_gdt_invalidate()) triggers an endless crash loop resulting in a kernel panic and complete system unavailability. No public exploit exists and EPSS is 0.02% (4th percentile), consistent with the highly constrained triggering environment - this primarily affects kernel developers and syzkaller-based fuzzing infrastructure rather than general-purpose production systems.

Technical ContextAI

The defect resides in the x86_64 kexec path, specifically machine_kexec_64.c and physaddr.c. During a kexec transition, load_segments() overwrites segment registers including the GS segment, which nullifies the GS base pointer. KCOV (Kernel Coverage), a kernel-internal instrumentation framework used for coverage-guided fuzzing, depends on GS-relative per-cpu storage to record trace data via __sanitizer_cov_trace_pc(). Once GS base is invalidated by load_segments(), every subsequent call to any KCOV-instrumented function attempts to dereference a corrupt or zeroed per-cpu pointer, producing a fault that itself re-enters the KCOV trace path before GS is restored, creating an irrecoverable loop. The fix - disabling KCOV instrumentation wholesale for the affected translation units - was preferred over per-function annotations (fragile) or adding a guard in the KCOV fast path (performance overhead). CWE is not assigned; the root cause class is an ordering/state-invalidation issue: a critical system register is modified before dependent instrumentation is disabled. CPE confirms the affected surface is cpe:2.3:o:linux:linux_kernel across multiple stable branches and the 7.0 release candidate series (rc1-rc6).

RemediationAI

Upgrade to Linux kernel 6.18.22, 6.19.12, or 7.0 (or later maintenance releases), which include the fix disabling KCOV instrumentation for machine_kexec_64.c and physaddr.c. The upstream fix commits are available at https://git.kernel.org/stable/c/1e3e98596c2769721ade0418434852fb3af4849a (one stable branch), https://git.kernel.org/stable/c/917e3ad3321e75ca0223d5ccf26ceda116aa51e1 (second stable branch), and https://git.kernel.org/stable/c/de05c66fab8847237a9ca216934e56d3ee837f08 (third branch). For environments that cannot immediately upgrade, the effective workaround is to rebuild the kernel with CONFIG_KCOV disabled; this eliminates the vulnerable code path entirely but removes coverage instrumentation capability, which may be acceptable for production hosts. Alternatively, disabling CONFIG_KEXEC removes the kexec trigger entirely at the cost of losing kdump/crash-kernel functionality. Neither workaround has side effects beyond the loss of the respective feature. Production systems that do not build custom kernels with CONFIG_KCOV require no action.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-43331 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy