linux-kernel - [Bug] soft lockup in syscall_exit_to_user

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

Message-ID: <CAP=Rh=OFdom8bL-KiWf88AyVZkJWnAJ+HBO7rE_74sOFzK=apQ@mail.gmail.com>
Date: Thu, 22 May 2025 00:40:29 +0800
From: John <john.cs.hey@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, linux-kernel@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org
Subject: [Bug] soft lockup in syscall_exit_to_user_mode in Linux kernel v6.15-rc5

Dear Linux Kernel Maintainers,

I hope this message finds you well.

I am writing to report a potential vulnerability I encountered during
testing of the Linux Kernel version v6.15-rc5.

Git Commit: 92a09c47464d040866cf2b4cd052bc60555185fb (tag: v6.15-rc5)

Bug Location: 0010:tracing_gen_ctx_irq_test+0x54/0x1f0 kernel/trace/trace.c:2538

Bug report: https://hastebin.com/share/asotenajan.bash

Complete log: https://hastebin.com/share/kurebaguxo.perl

Entire kernel config:  https://hastebin.com/share/padecilimo.ini

Root Cause Analysis:
The root cause is unbounded recursion or excessive iteration in
lock_acquire() initiated via perf tracepoints that fire during slab
allocations and trace buffer updates. Specifically:
tracing_gen_ctx_irq_test() is invoked while tracing kernel contexts
(e.g., IRQ/softirq nesting).
This tracepoint triggers perf_trace_lock_acquire() and further invokes
lock_acquire() from lockdep.
Inside lock_acquire(), the kernel attempts to inspect instruction
addresses via __kernel_text_address(), which cascades into
unwind_get_return_address() and stack_trace_save().
However, these introspection functions are not expected to run in
real-time-sensitive softirq context and they do not contain preemption
or rescheduling points. With sufficient recursion or stress (e.g.,
slab allocation with tracepoints and lockdep active), CPU#0 gets
trapped and triggers the watchdog.

At present, I have not yet obtained a minimal reproducer for this
issue. However, I am actively working on reproducing it, and I will
promptly share any additional findings or a working reproducer as soon
as it becomes available.

Thank you very much for your time and attention to this matter. I
truly appreciate the efforts of the Linux kernel community.

Best regards,
John