linux-kernel - Re: [PATCH v3 22/28] x86: Use RCU in all users of __module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251103113750.qam3KIkT@linutronix.de>
Date: Mon, 3 Nov 2025 12:37:50 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Michal Pecio <michal.pecio@...il.com>
Cc: bp@...en8.de, da.gomez@...sung.com, dave.hansen@...ux.intel.com,
	hpa@...or.com, jpoimboe@...nel.org, linux-kernel@...r.kernel.org,
	linux-modules@...r.kernel.org, mcgrof@...nel.org, mingo@...hat.com,
	paulmck@...nel.org, peterz@...radead.org, petr.pavlu@...e.com,
	samitolvanen@...gle.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: [PATCH v3 22/28] x86: Use RCU in all users of __module_address().

On 2025-11-03 11:39:07 [+0100], Michal Pecio wrote:
> Sorry, I forgot to include the link. There is also a similar warning
> regarding __this_cpu_read(). Pretty sure the kernel is SMP.
> 
> https://bbs.archlinux.org/viewtopic.php?id=309960

The stack trace is a bit odd. The compressed version is:
| BUG: using smp_processor_id() in preemptible [00000000] code: Xorg/1183
| caller is in_entry_stack+0x11/0x60
| CPU: 3 UID: 1000 PID: 1183 Comm: Xorg Tainted: P           OE       6.16.12-hardened1-1-hardened #1 PREEMPT(full)  6edb90a7a07fab33bbee72d6d5ef53ba6eec3b9c
| Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
| Hardware name: ASUS All Series/Z97-E, BIOS 0803 02/23/2016
| Call Trace:
|  <TASK>
|  dump_stack_lvl+0x5d/0x80
|  check_preemption_disabled+0xe5/0xf0
|  in_entry_stack+0x11/0x60
|  get_stack_info+0x2c/0x80
|  stack_access_ok+0x51/0xa0
|  unwind_next_frame+0x1cb/0x7b0
|  arch_stack_walk+0xa6/0x110
|  stack_trace_save+0x4d/0x70
|  __kfence_alloc+0xb7/0x6f0
|  __kmalloc_noprof+0x520/0x560
|  os_alloc_mem+0x108/0x120 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv015295rm+0x34/0x50 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv015297rm+0x2b/0xd0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv016352rm+0x1c/0x90 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv059298rm+0x65/0xb0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv054041rm+0x20f/0x360 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv056165rm+0x54/0xd0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv056096rm+0xa0/0x500 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv015919rm+0x424/0x680 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv054015rm+0x69/0xd0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv014185rm+0x86/0xa0 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  _nv000652rm+0x5e/0x70 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  rm_kernel_rmapi_op+0x167/0x273 [nvidia 9746d397d5c5bffeb186e829669bb24c0846a4a7]
|  nvkms_call_rm+0x4c/0x80 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
|  _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
|  ? do_syscall_64+0x82/0x8d0
|  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
|  </TASK>

The last two entries start with a '?' which means it did not originate
from the "stack unwind" but was laying around while passing through.
I would expect the last two entries to be there without the '?' because
userland (as in X here) enters the kernel via a proper syscall entry
which should be part of the stack strace.

Now, get_stack_info() where the warning originates: It starts with a
check to see if the stack pointer belongs to the current task's stack
frame which it does not. Then it checks if the task found is the
currently running task. That it does. So in that case, we must be
serving an exception (such as an IRQ) because the stack does not belong
to the current task.  However preemption is not disabled which indicates
that we do not do this.
This in turn suggests that nvidia replaced the stack from while entering
the syscall probably in _nv003168kms() or the binary blob which invokes
the kernel function does not have a proper ORC entry which leads to a
wrong turn in the process.

So the warning is well deserved.

Sebastian