[PATCH] x86/kexec: Disable KCOV instrumentation after load_segments()

[Aleksandr Nogikh]

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

(additional problems arise when the kernel is booting into a crash
kernel)

Disabling instrumentation for the individual functions would be too
fragile, so let's fix the bug by disabling KCOV instrumentation for
the whole machine_kexec_64.c and physaddr.c.

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

Signed-off-by: Aleksandr Nogikh <nog...@google.com>
Cc: sta...@vger.kernel.org
---
arch/x86/kernel/Makefile | 4 ++++
arch/x86/mm/Makefile | 4 ++++
2 files changed, 8 insertions(+)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index e9aeeeafad173..5703fa6027866 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -43,6 +43,10 @@ KCOV_INSTRUMENT_dumpstack_$(BITS).o := n
KCOV_INSTRUMENT_unwind_orc.o := n
KCOV_INSTRUMENT_unwind_frame.o := n
KCOV_INSTRUMENT_unwind_guess.o := n
+# When a kexec kernel is loaded, calling load_segments() breaks all
+# subsequent KCOV instrumentation until new kernel takes control.
+# Keep KCOV instrumentation disabled to prevent kernel crashes.
+KCOV_INSTRUMENT_machine_kexec_64.o := n

CFLAGS_head32.o := -fno-stack-protector
CFLAGS_head64.o := -fno-stack-protector
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 5b9908f13dcfd..a678a38a40266 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -4,6 +4,10 @@ KCOV_INSTRUMENT_tlb.o := n
KCOV_INSTRUMENT_mem_encrypt.o := n
KCOV_INSTRUMENT_mem_encrypt_amd.o := n
KCOV_INSTRUMENT_pgprot.o := n
+# When a kexec kernel is loaded, calling load_segments() breaks all
+# subsequent KCOV instrumentation until new kernel takes control.
+# Keep KCOV instrumentation disabled to prevent kernel crashes.
+KCOV_INSTRUMENT_physaddr.o := n

KASAN_SANITIZE_mem_encrypt.o := n
KASAN_SANITIZE_mem_encrypt_amd.o := n
--
2.53.0.273.g2a3d683680-goog

[Aleksandr Nogikh]

On Mon, Feb 16, 2026 at 6:37 PM Aleksandr Nogikh <nog...@google.com> wrote:
>
> 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
>
> (additional problems arise when the kernel is booting into a crash
> kernel)
>
> Disabling instrumentation for the individual functions would be too
> fragile, so let's fix the bug by disabling KCOV instrumentation for
> the whole machine_kexec_64.c and physaddr.c.
>
> The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not
> supported there.
>
> Signed-off-by: Aleksandr Nogikh <nog...@google.com>
> Cc: sta...@vger.kernel.org
> ---
> arch/x86/kernel/Makefile | 4 ++++
> arch/x86/mm/Makefile | 4 ++++
> 2 files changed, 8 insertions(+)

A gentle ping on this patch.

Should it go through the x86 tree or the mm tree like other kcov patches?

[Dmitry Vyukov]

On Mon, 16 Feb 2026 at 18:37, Aleksandr Nogikh <nog...@google.com> wrote:
>
> 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
>
> (additional problems arise when the kernel is booting into a crash
> kernel)
>
> Disabling instrumentation for the individual functions would be too
> fragile, so let's fix the bug by disabling KCOV instrumentation for
> the whole machine_kexec_64.c and physaddr.c.
>
> The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not
> supported there.
>
> Signed-off-by: Aleksandr Nogikh <nog...@google.com>
> Cc: sta...@vger.kernel.org

Reviewed-by: Dmitry Vyukov <dvy...@google.com>

[Aleksandr Nogikh]

+Cc linux-mm

[Borislav Petkov]

On Mon, Feb 16, 2026 at 06:37:16PM +0100, Aleksandr Nogikh wrote:
> Disabling instrumentation for the individual functions would be too
> fragile, so let's fix the bug by disabling KCOV instrumentation for
> the whole machine_kexec_64.c and physaddr.c.

Seems like a whack-a-mole thing to me. Why not make KEXEC depend on !KCOV?

--
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[Aleksandr Nogikh]

On Sun, Mar 15, 2026 at 1:19 PM Borislav Petkov <b...@alien8.de> wrote:
>
> On Mon, Feb 16, 2026 at 06:37:16PM +0100, Aleksandr Nogikh wrote:
> > Disabling instrumentation for the individual functions would be too
> > fragile, so let's fix the bug by disabling KCOV instrumentation for
> > the whole machine_kexec_64.c and physaddr.c.
>
> Seems like a whack-a-mole thing to me. Why not make KEXEC depend on !KCOV?

Some more context:
The problem I am trying to solve is enabling crash dump collection in
syzkaller. For this, the tool loads a panic kernel before fuzzing and
then calls makedumpfile after the panic (which fails due to the bug I
mentioned in the patch). It requires both KEXEC and KCOV.

The most whack-a-mole solution was to disable instrumentation for
several functions called after load_segments(); this particular patch
is more generic, but yes, it can still be fragile. Another approach
would be to add more checks to
__sanitizer_cov_trace_pc()/check_kcov_mode(), but this would also be
somewhat undesirable as it would slow KCOV down even further.

--
Aleksandr

[Borislav Petkov]

On Mon, Mar 16, 2026 at 11:07:15AM +0100, Aleksandr Nogikh wrote:
> Some more context:
> The problem I am trying to solve is enabling crash dump collection in
> syzkaller. For this, the tool loads a panic kernel before fuzzing and
> then calls makedumpfile after the panic (which fails due to the bug I
> mentioned in the patch). It requires both KEXEC and KCOV.
>
> The most whack-a-mole solution was to disable instrumentation for
> several functions called after load_segments(); this particular patch
> is more generic, but yes, it can still be fragile. Another approach
> would be to add more checks to
> __sanitizer_cov_trace_pc()/check_kcov_mode(), but this would also be
> somewhat undesirable as it would slow KCOV down even further.

I guess...

So I'd like the *real* justification - the context you just gave - for this
to be put somewhere over the code, I guess in both Makefiles so that it is
clear why we're doing this.

I guess those two compilation units will be excluded from KCOV fuzzing and if
someone wants to do coverage-guided fuzzing for them, then someone would have
to come up with a different solution, like, I dunno, putting only the
relevant, simple functions into a separate compilation unit which would be the
only one excluded from KCOV instrumentation or something more clever and less
whack-a-mole-y...

Thx.

[Aleksandr Nogikh]

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 let's fix the bug by disabling KCOV instrumentation for

the entire machine_kexec_64.c and physaddr.c. If coverage-guided
fuzzing ever needs these components in the future, we should consider
other approaches.

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

Reviewed-by: Dmitry Vyukov <dvy...@google.com>

Signed-off-by: Aleksandr Nogikh <nog...@google.com>
Cc: sta...@vger.kernel.org

---
v2:
Updated the comments to explain the underlying context.

v1:
https://lore.kernel.org/all/20260216173716....@google.com/
---
arch/x86/kernel/Makefile | 10 ++++++++++
arch/x86/mm/Makefile | 10 ++++++++++
2 files changed, 20 insertions(+)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index e9aeeeafad173..41b1333907ded 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -43,6 +43,16 @@ KCOV_INSTRUMENT_dumpstack_$(BITS).o := n

KCOV_INSTRUMENT_unwind_orc.o := n
KCOV_INSTRUMENT_unwind_frame.o := n
KCOV_INSTRUMENT_unwind_guess.o := n

+# Disable KCOV to prevent crashes during kexec: load_segments() invalidates
+# the GS base, which KCOV relies on for per-CPU data.
+# As KCOV && KEXEC compatibility should be preserved (e.g. syzkaller is
+# using it to collect crash dumps during kernel fuzzing), we could either
+# selectively disable KCOV instrumentation, which can be fragile, or add
+# more checks to KCOV, which would slow it down.
+# As a compromise solution, let's disable KCOV instrumentation for the
+# whole file. If its coverage is ever needed, we should consider other
+# approaches.

+KCOV_INSTRUMENT_machine_kexec_64.o := n

CFLAGS_head32.o := -fno-stack-protector
CFLAGS_head64.o := -fno-stack-protector
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile

index 5b9908f13dcfd..ea3a31b54e49e 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -4,6 +4,16 @@ KCOV_INSTRUMENT_tlb.o := n

KCOV_INSTRUMENT_mem_encrypt.o := n
KCOV_INSTRUMENT_mem_encrypt_amd.o := n
KCOV_INSTRUMENT_pgprot.o := n

+# Disable KCOV to prevent crashes during kexec: load_segments() invalidates
+# the GS base, which KCOV relies on for per-CPU data.
+# As KCOV && KEXEC compatibility should be preserved (e.g. syzkaller is
+# using it to collect crash dumps during kernel fuzzing), we could either
+# selectively disable KCOV instrumentation, which can be fragile, or add
+# more checks to KCOV, which would slow it down.
+# As a compromise solution, let's disable KCOV instrumentation for the
+# whole file. If its coverage is ever needed, we should consider other
+# approaches.

+KCOV_INSTRUMENT_physaddr.o := n

KASAN_SANITIZE_mem_encrypt.o := n
KASAN_SANITIZE_mem_encrypt_amd.o := n

base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
--
2.53.0.959.g497ff81fa9-goog

[Borislav Petkov]

On Tue, Mar 17, 2026 at 11:03:19PM +0100, Aleksandr Nogikh wrote:
> 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 let's fix the bug by disabling KCOV instrumentation for
> the entire machine_kexec_64.c and physaddr.c. If coverage-guided
> fuzzing ever needs these components in the future, we should consider

^^

Please use passive voice in your commit message: no "we" or "I", etc,
and describe your changes in imperative mood.

Also in the comments below.

> other approaches.
>
> The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not
> supported there.
>
> Reviewed-by: Dmitry Vyukov <dvy...@google.com>
> Signed-off-by: Aleksandr Nogikh <nog...@google.com>
> Cc: sta...@vger.kernel.org
> ---
> v2:
> Updated the comments to explain the underlying context.
>
> v1:
> https://lore.kernel.org/all/20260216173716....@google.com/
> ---
> arch/x86/kernel/Makefile | 10 ++++++++++
> arch/x86/mm/Makefile | 10 ++++++++++
> 2 files changed, 20 insertions(+)

./scripts/checkpatch.pl /tmp/current.patch

...

WARNING: The commit message has 'stable@', perhaps it also needs a 'Fixes:' tag?

Instead of repeating this big comment block, just say something along the
lines of:

# See "Disable KCOV" comment in arch/x86/kernel/Makefile

> +KCOV_INSTRUMENT_physaddr.o := n
>
> KASAN_SANITIZE_mem_encrypt.o := n
> KASAN_SANITIZE_mem_encrypt_amd.o := n
>
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> --