[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXE2rN-erQNnSZ5-CGKWw6fCQ6Hvz-2BU1pn-Vy7ftneQA@mail.gmail.com>
Date: Fri, 26 Dec 2025 11:10:02 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, linux-efi@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
riel@...riel.com, puranjay@...nel.org, usamaarif642@...il.com,
kernel-team@...a.com
Subject: Re: [PATCH 0/2] arm64: efi: Fix NULL pointer crash in 6.19-rc2
On Tue, 23 Dec 2025 at 11:56, Breno Leitao <leitao@...ian.org> wrote:
>
> 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@...ian.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()
>
Thanks for the report - I've queued these up in the EFI fixes tree.
> 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@...ian.org>
>
>
Powered by blists - more mailing lists