linux-kernel - Stack backtrace is using the user RIP to read kernel instructions

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>] [day] [month] [year] [list]

Message-ID: <ba26737a487946718d7632fdc77988db@AcuMS.aculab.com>
Date:   Thu, 10 Feb 2022 11:27:48 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Stack backtrace is using the user RIP to read kernel instructions

I got the following 'splat' on a 5.17.0-rc3 kernel:

BUG: scheduling while atomic: xxx
Modules linked in: xxx
Preemption disabled at:
xxx+0x3c/0xd0 [xxx]
CPU: 5 PID: 28197 Comm: xxx Tainted: P           OE     5.16.0-rc7+ #29
Hardware name: Supermicro X11SSV-Q/X11SSV-Q, BIOS 2.2b 02/12/2018
Call Trace:
 <TASK>
 dump_stack_lvl+0x4c/0x63
 (valid kernel stack)
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f90ea1febd6
Code: Unable to access opcode bytes at RIP 0x7f90ea1febac.
RSP: 002b:00007ffde8cd8188 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00007f90ea501740 RCX: 00007f90ea1febd6
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
R10: 00007f90ea1152a0 R11: 0000000000000246 R12: 00007f90ea501740
R13: 0000000000000001 R14: 00007f90ea50a708 R15: 0000000000000000
 </TASK>

The problem is all mine :-)
(Someone added a spin_lock_irqsave() around code that does msleep(1).)

But the dump of the opcode bytes is missing.
I think these would be the user code for the syscall (so boring).
OTOH I can't really imagine the code got swapped out.

I can't quite decide whether copy_code() (in dumpstack.c) tried to call
copy_from_kernel_nofault() and failed because of the user address,
or copy_from_user_nmi() failed.

But something is awry somewhere.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)