From nobody Mon Apr 6 21:32:22 2026 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25CB219CC0C for ; Tue, 17 Mar 2026 22:03:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773785007; cv=none; b=e1LKoTjQQWfUEp25w6SIZuiOJ+B9aate6nAVZhDym4SZuXjzp668hf8dizCXlFfiQrbsh+lFwXkenYHH/zfcf2GGRFBD774X/qKtmcudMladHULxqgpd/bF1FTr/XgVOhd7Jq4gRM2aNKMZJeQ/qhySl04Kn021nV8SqZmIGJ/Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773785007; c=relaxed/simple; bh=oU3OVhNKPZI6FrfLf4b3tz8GEz5wRhmrq2qNQQUyCnY=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=tqpJV5gGXk1cK09F56mPhFcJFNBMMpmPaHFGxsAA9Bf+MJ2Hg3lILBjmn533GH2212sUcKFMeS41tWj1Q/SxHHimUcvEW4wESTFB02AdZxKKzCyTuoS7+AAcFpYPyFBi3Mrgk5SnyQNH0BODHjYy/lDKFLxgx/1Cxp+9Iydm9iY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--nogikh.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=gdrR6vxf; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--nogikh.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="gdrR6vxf" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-48553fdd03dso36017455e9.0 for ; Tue, 17 Mar 2026 15:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773785004; x=1774389804; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=a5ROHSj5Kev7hvsbjDyb4mWRpxoAV8o5zFiVg3Mbgk4=; b=gdrR6vxfLZs4p3VvRvGjUtPXUtp/vwYI8n613Zm0GD/pNpF/fdVOHepVTYl1eob9cv HqNcsPBiNM8fMvtjBAukkYICIz3asFzoO3Ha7JEudG56wmD1F6VpZfAu/nciwt+M0geC FpQg1FapsGDEXRAw31rf1kifY+p/k0J7nQwZZiYDHyNcTOnMmfq9VfmAZTunCq6Vwpyo HMwRxn1qqdQwGr4Og+Yo9yK59gEtqz1oUeW3w3lOPQfi6Vo/6f48XkooDBx/n3OpdFpB SaY+W6eKeupMVd3N9qIP8Hji1ba3fF6TGBeMYFli6eKHBoysLoTL5dsIE31zMkgBec3Q 0QbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773785004; x=1774389804; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=a5ROHSj5Kev7hvsbjDyb4mWRpxoAV8o5zFiVg3Mbgk4=; b=MZ7gP+WZWyLVZbmT0CszOrqMldec8hcCZ2A0BDqVCNRaiYI4mtlZ898rT2QPVNgsEZ bVY+FueNZVQduicf/zCluORO7y2JO+JVM59Zcg6D0tdQOgzFCKyYfXaqVnWIiGRE8f7h sBPuMMKoRktjZ/O/atN1imw09dFC0QMLGsebI5tHSUZfoLkvOh4SqL9UW/JEGmRLmEMp wW4IL9ZBHLTS3jL2KinVegcH5WqQy0wPuZSeGFzXbBkYv2dEMr9QDI98AC9PEYXAQNb/ rJHN5nKDdGJJ7J0inJ0XIhd1ggSGSREnkuX7yCcGoLDbmRqoXCO7gJWgEueiioTuPMQB aKJw== X-Forwarded-Encrypted: i=1; AJvYcCWguj/QVfzcpq2YbIgqu9HlBXPsbJCnEs/3b1XnZaCe+ADml9mRhmzJSpfISNxitWJLEzxPjPXYiHTu/rc=@vger.kernel.org X-Gm-Message-State: AOJu0YzbZuEY5OIesgcZBkrzrQMrIvsm3vZ8WuOccHwMsP/Xhkw81Xzt 9itcZ69x6TuYmCT5T2sTk8krw+M/XEnj2pn4WYM+r0LXVUxBlM9imvE8S9dDw/f5Nl+BH8vipqb 1xLV3Og== X-Received: from wmpo21.prod.google.com ([2002:a05:600c:3395:b0:483:b1c6:5b34]) (user=nogikh job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:3514:b0:485:3a03:ced1 with SMTP id 5b1f17b1804b1-486f458107fmr19079455e9.28.1773785004419; Tue, 17 Mar 2026 15:03:24 -0700 (PDT) Date: Tue, 17 Mar 2026 23:03:19 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.53.0.959.g497ff81fa9-goog Message-ID: <20260317220319.788561-1-nogikh@google.com> Subject: [PATCH v2] x86/kexec: Disable KCOV instrumentation after load_segments() From: Aleksandr Nogikh To: bp@alien8.de, tglx@kernel.org, mingo@redhat.com Cc: x86@kernel.org, linux-kernel@vger.kernel.org, dvyukov@google.com, kasan-dev@googlegroups.com, linux-mm@kvack.org, Aleksandr Nogikh , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 Signed-off-by: Aleksandr Nogikh Cc: stable@vger.kernel.org --- v2: Updated the comments to explain the underlying context. v1: https://lore.kernel.org/all/20260216173716.2279847-1-nogikh@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 :=3D n KCOV_INSTRUMENT_unwind_orc.o :=3D n KCOV_INSTRUMENT_unwind_frame.o :=3D n KCOV_INSTRUMENT_unwind_guess.o :=3D 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 :=3D n =20 CFLAGS_head32.o :=3D -fno-stack-protector CFLAGS_head64.o :=3D -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 :=3D n KCOV_INSTRUMENT_mem_encrypt.o :=3D n KCOV_INSTRUMENT_mem_encrypt_amd.o :=3D n KCOV_INSTRUMENT_pgprot.o :=3D 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 :=3D n =20 KASAN_SANITIZE_mem_encrypt.o :=3D n KASAN_SANITIZE_mem_encrypt_amd.o :=3D n base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c --=20 2.53.0.959.g497ff81fa9-goog