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: <20251103113907.4e647f33.michal.pecio@gmail.com>
Date: Mon, 3 Nov 2025 11:39:07 +0100
From: Michal Pecio <michal.pecio@...il.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
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 Mon, 3 Nov 2025 11:34:34 +0100, Sebastian Andrzej Siewior wrote:
> On 2025-11-03 11:08:35 [+0100], Michal Pecio wrote:
> > Hi,  
> Hi,
> 
> > There is a regression report on a distribution forum which involves
> > an out of tree module on a patched kernel (yes, I know) calling
> > stack_trace_save() in task context, which arrives here and apparently
> > calls the various deref_stack_xxx() functions with preemption enabled,
> > which in turn call stack_access_ok() leading to a BUG:
> > 
> > Nov 02 21:44:30 ArchBasement kernel: BUG: using smp_processor_id() in preemptible [00000000] code: Xorg/1183
> > Nov 02 21:44:30 ArchBasement kernel: caller is in_entry_stack+0x11/0x60
> > Nov 02 21:44:30 ArchBasement kernel: CPU: 0 UID: 1000 PID: 1183 Comm: Xorg Tainted: P           OE       6.16.12-hardened1-1-hardened #1 PREEMPT(full)  6edb90a7a07fab33bbee72d6d5ef53ba6eec3b9c
> > Nov 02 21:44:30 ArchBasement kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> > Nov 02 21:44:30 ArchBasement kernel: Hardware name: ASUS All Series/Z97-E, BIOS 0803 02/23/2016
> > Nov 02 21:44:30 ArchBasement kernel: Call Trace:
> > Nov 02 21:44:30 ArchBasement kernel:  <TASK>
> > Nov 02 21:44:30 ArchBasement kernel:  dump_stack_lvl+0x5d/0x80
> > Nov 02 21:44:30 ArchBasement kernel:  check_preemption_disabled+0xe5/0xf0
> > Nov 02 21:44:30 ArchBasement kernel:  in_entry_stack+0x11/0x60
> > Nov 02 21:44:30 ArchBasement kernel:  get_stack_info+0x2c/0x80
> > Nov 02 21:44:30 ArchBasement kernel:  stack_access_ok+0x51/0xa0
> > Nov 02 21:44:30 ArchBasement kernel:  unwind_next_frame+0x1cb/0x7b0
> > Nov 02 21:44:30 ArchBasement kernel:  ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
> > Nov 02 21:44:30 ArchBasement kernel:  ? __pfx_stack_trace_consume_entry+0x10/0x10
> > Nov 02 21:44:30 ArchBasement kernel:  arch_stack_walk+0xa6/0x110
> > Nov 02 21:44:30 ArchBasement kernel:  ? _nv003168kms+0x42/0x50 [nvidia_modeset 90775ea8a26c5e58b97ef4b3f46eb45efa040eb2]
> > Nov 02 21:44:30 ArchBasement kernel:  stack_trace_save+0x4d/0x70
> > 
> > Is this nvidia doing something wrong, or a problem with this commit?
> > 
> > The removed code suggests that preemption is allowed here, and as far
> > as I see, this call trace is still possible on vanilla 6.18. Perhaps
> > preempt_disable() needs to be restored around this code?  
> 
> Do you have the complete backtrace? Is this SMP or UP build?

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