public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Ard Biesheuvel <ardb@kernel.org>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org, riel@surriel.com,
	puranjay@kernel.org,  usamaarif642@gmail.com,
	Breno Leitao <leitao@debian.org>,
	 kernel-team@meta.com
Subject: [PATCH 0/2] arm64: efi: Fix NULL pointer crash in 6.19-rc2
Date: Tue, 23 Dec 2025 02:55:42 -0800	[thread overview]
Message-ID: <20251223-efi_fix_619-v1-0-e0146b8b9d73@debian.org> (raw)

I am seeing the following crash on arm64 with 6.19-rc2 (commit 9448598b22c5
("Linux 6.19-rc2"))

	Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c8

	Call trace:
	cap_capable (security/commoncap.c:82 security/commoncap.c:128) (P)
	security_capable (security/security.c:?)
	ns_capable_noaudit (kernel/capability.c:342 kernel/capability.c:381)
	__ptrace_may_access (./include/linux/rcupdate.h:895 kernel/ptrace.c:326)
	ptrace_may_access (kernel/ptrace.c:353)
	do_task_stat (fs/proc/array.c:467)
	proc_tgid_stat (fs/proc/array.c:673)
	proc_single_show (fs/proc/base.c:803)
	seq_read_iter (fs/seq_file.c:209)
	seq_read (./include/linux/ioprio.h:59 ./include/linux/ioprio.h:84 ./include/linux/fs.h:2177 fs/seq_file.c:158)
	vfs_read (./arch/arm64/include/asm/uaccess.h:46 fs/read_write.c:560)
	ksys_read (fs/read_write.c:705)
	__arm64_sys_read (fs/read_write.c:722)
	invoke_syscall (arch/arm64/kernel/syscall.c:46)
	el0_svc_common+0x90/0xe0
	do_el0_svc (arch/arm64/kernel/syscall.c:150)
	el0_svc (arch/arm64/kernel/entry-common.c:724)
	el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:743)
	el0t_64_sync (arch/arm64/kernel/entry.S:596)

This was bissected to commit a5baf582f4 ("arm64/efi: Call EFI runtime services without
disabling preemption").

After the commit above, it crashes arm64 with a NULL pointer dereference in
cap_capable() when running below (ocassionally). Unfortunately I still don't
have a simple reproducer, and it takes about 10 minutes to crash on my systems.
it always crash with below[1] application.

From my investigation, the root cause is that efi_mm lacks user_ns
initialization. When kthread_use_mm(&efi_mm) temporarily adopts efi_mm
for EFI calls, LSM hooks expect mm->user_ns to be valid for credential
checks. With it being NULL, capability checks crash.

This series contains two patches:

1. efi: Initialize efi_mm.user_ns to &init_user_ns (the actual fix)
2. kthread: Add WARN_ON_ONCE() to catch similar bugs early (RFC)

The second patch is mostly an RFC that adds a warning in
kthread_use_mm() to detect any mm_struct missing user_ns initialization,
helping prevent similar NULL pointer crashes in the future.

Link: https://github.com/facebookincubator/below [1]

Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (2):
      arm64: efi: Fix NULL pointer dereference by initializing user_ns
      kthread: Warn if mm_struct lacks user_ns in kthread_use_mm()

 drivers/firmware/efi/efi.c | 1 +
 kernel/kthread.c           | 1 +
 2 files changed, 2 insertions(+)
---
base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
change-id: 20251223-efi_fix_619-3891ca7d2914

Best regards,
--  
Breno Leitao <leitao@debian.org>


             reply	other threads:[~2025-12-23 10:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-23 10:55 Breno Leitao [this message]
2025-12-23 10:55 ` [PATCH 1/2] arm64: efi: Fix NULL pointer dereference by initializing user_ns Breno Leitao
2025-12-23 19:24   ` Rik van Riel
2025-12-23 10:55 ` [PATCH 2/2] kthread: Warn if mm_struct lacks user_ns in kthread_use_mm() Breno Leitao
2025-12-23 19:31   ` Rik van Riel
2025-12-26 10:10 ` [PATCH 0/2] arm64: efi: Fix NULL pointer crash in 6.19-rc2 Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251223-efi_fix_619-v1-0-e0146b8b9d73@debian.org \
    --to=leitao@debian.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@meta.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=puranjay@kernel.org \
    --cc=riel@surriel.com \
    --cc=usamaarif642@gmail.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox