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
