CVE-2026-43331

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. ]
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:*

History

11 Nov 2026, 20:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: x86/kexec: Deshabilitar la instrumentación KCOV después de load_segments() La función load_segments() cambia los registros de segmento, invalidando la base GS (en la que KCOV se basa para los datos por CPU). Cuando CONFIG_KCOV está habilitado, cualquier llamada posterior a código C instrumentado (por ejemplo, native_gdt_invalidate()) comienza a bloquear el kernel en un bucle infinito. Para reproducir el problema, es suficiente con hacer kexec en un kernel instrumentado con KCOV: $ kexec -l /boot/otherKernel $ kexec -e El contexto real de este problema es la habilitación de la recolección de volcados de fallos en syzkaller. Para esto, la herramienta carga un kernel de pánico antes del fuzzing y luego llama a makedumpfile después del pánico. Este flujo de trabajo requiere que tanto CONFIG_KEXEC como CONFIG_KCOV estén habilitados simultáneamente. Añadir salvaguardas directamente a la ruta rápida de KCOV (__sanitizer_cov_trace_pc()) también es indeseable ya que introduciría una sobrecarga de rendimiento adicional. Deshabilitar la instrumentación para las funciones individuales sería demasiado frágil, así que se deshabilita la instrumentación KCOV para todo machine_kexec_64.c y physaddr.c. Si el fuzzing guiado por cobertura alguna vez necesita estos componentes en el futuro, se deberían considerar otros enfoques. El problema no es relevante para kernels de 32 bits ya que CONFIG_KCOV no es compatible allí. [ bp: Espaciar el comentario para una mejor legibilidad. ]

Information

Published : 2026-05-08 14:16

Updated : 2026-11-11 20:10


NVD link : CVE-2026-43331

Mitre link : CVE-2026-43331

CVE.ORG link : CVE-2026-43331


JSON object : View

Products Affected

linux

  • linux_kernel