| 0/0 |
2026/05/15 17:50 |
flow |
assessment-security |
31m
Results: map[DenialOfService:true Explanation:The analysis of the bug report reveals the following sequence of events:
1. **The Panic**: The kernel panicked with `corrupted stack end detected inside
scheduler`. This happens in `__schedule()` when it checks the `STACK_END_MAGIC`
at the bottom of the task's stack and finds it overwritten.
2. **The Victim**: The panic occurred in `swapper/0` (PID 0), which is the idle
thread. Its stack is statically allocated as `init_stack`.
3. **The Corrupted Value**: The registers dump shows `r3:57ac6e9d` (which is the
expected `STACK_END_MAGIC`) and `r2:8280001c`. Given that `init_stack` is
typically aligned to `THREAD_SIZE` (e.g., `0x82800000`), `0x8280001c` is an
address exactly `0x1c` bytes into the stack. This strongly indicates that a
stack frame pointer or saved stack pointer was pushed to the very bottom of the
stack, overwriting the magic value.
4. **The Root Cause**: The kernel is tainted with `[L]=SOFTLOCKUP`. This means
that prior to the panic, the CPU was stuck in a loop for at least 20 seconds,
and the softlockup watchdog timer interrupt fired. When the watchdog fires, it
prints a warning and calls `dump_stack()`.
5. **The Mechanism**: If the CPU was stuck in a deep call chain or a softirq
handler (e.g., processing a complex network packet or malicious input), the task
stack was already mostly full. The additional stack frames pushed by the
watchdog's `dump_stack()` caused the stack to overflow, overwriting
`init_stack[0]`. After the watchdog interrupt returned, the long loop eventually
finished, and the CPU returned to the idle loop. When `do_idle()` called
`__schedule()`, the corrupted magic value was detected, triggering the panic.
**Security Impact Assessment:**
* **Exploitable**: **No**. The stack overflow is a secondary effect caused by
the kernel's own `dump_stack()` function pushing return addresses and frame
pointers. It does not involve attacker-controlled data being written
out-of-bounds, making it unexploitable for privilege escalation or arbitrary
code execution.
* **Denial of Service**: **Yes**. The primary bug is a softlockup (an infinite
or excessively long loop in the kernel), which halts the CPU and leads to a
system crash/panic.
* **Accessible From Unprivileged Processes / User Namespaces**: **Yes**.
Syzkaller runs as an unprivileged user (often within user namespaces) and was
able to trigger the softlockup, indicating that no special privileges are
required.
* **Specific Triggers**: Unknown. The exact subsystem (network, filesystem,
etc.) where the softlockup occurred is not specified in the trace. We err on the
side of caution and assume they are not specifically required. Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 1/1 |
2026/05/15 17:50 |
action |
syz-repro-to-c-repro |
0m
Results:
|
| 2/1 |
2026/05/15 17:50 |
action |
kernel-checkouter |
2m
Results: map[KernelSrc:/app/workdir/cache/src/68b1644a07167f990af784849cc844972ce3d502]
|
| 3/1 |
2026/05/15 17:52 |
action |
kernel-builder |
8m
Results: map[KernelObj:/app/workdir/cache/build/9f64d327bdbee13bf7acc7c336db5c02334eb278]
|
| 4/1 |
2026/05/15 18:01 |
action |
codesearch-prepare |
13m
Results: map[Index:codesearch-index]
|
| 5/1 |
2026/05/15 18:14 |
agent |
expert |
7m
Model:
Results: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Instruction:
You are an experienced Linux kernel security engineer. Your task is to analyze given kernel bug report
and determine its security impact based on the following dimensions.
Use the provided tools to examine the source code, check for capability checks (e.g., capable(), ns_capable()),
and understand the nature of the bug. Analyze the given kernel build and configuration.
You can check the kernel config by grepping ".config" file; you can check kernel cmdline by greeping
".config" file for "CONFIG_CMDLINE=". Assume sysctl parameters have default values.
But analyze for the corresponding production build w/o debugging tools enabled (like KASAN, KMSAN, UBSAN).
Don't make assumptions; verify them with source code access. Try different strategies when analyzing the bug:
- think of ways in which the vulnerable code is unreachable
- or the other way around: try to come up with different ideas of how an unprivileged user can reach the bug
If still unsure err on the side of the bug being non-exploitable/not-accessible.
In the final reply, provide a reasoning for your assessment.
Analysis dimensions:
* Exploitable:
Determine if the bug can result in memory corruption or elevated privileges.
Memory safety issues are almost always exploitable (KASAN or UBSAN reports for use-after-free, out-of-bounds;
refcounting issues, corrupted lists, etc). When kernel is crashing on a completly wild pointer access
(e.g. user-space address, or non-canonical address, but not on NULL or address corresponding to KASAN shadow
for NULL address), including both data accesses and control tranfers, that's also usually implies possibility
of exploitation. Such reports usually say "unable to handle kernel paging request".
Uses of uninitialized values detected by KMSAN may be exploitable b/c attacker frequently can affect uninit
values with spraying techniques. However, for these exploitabability depends on how exactly the uninit value
is used in the code, and what it affects.
Think of what happens after the bug is triggered. Some bugs cause kernel panic and halt execution,
they are harder to exploit. For example, BUG reports halts the kernel. However, WARNING reports don't halt
execution in production builds. Debug bug detection tools (like KASAN, KMSAN, KCSAN, UBSAN) are also not enabled
in production builds, so attacker can freely exploit these bugs w/o being detected by these tools.
If you see an integer overflow, think how the overflowed value used later (if it's used as allocation size,
or an array index). If you see an out-of-bounds read, think if it's followed by an out-of-bounds write as well.
Some KCSAN data-races may be exploitable by skilled attackers as well. Think what data structures got corrupted
as the result of data races and how. However, note that kernel has lots of "benign" data races that don't lead
to any runtime misbehavior at all.
* Denial Of Service:
Determine if the bug can result in denial-of-service. Most bugs can, since they cause system crash,
hangs, deadlocks, or resource leaks. This is mostly applicable to WARNING bugs that won't cause system crash
in production. For these think what will be consequences of the violation of the kernel assumptions flagged
by the WARNING. In some cases the unexpected condition is also properly handled by the normal control flow
(e.g. with "if (WARN_ON(...))"), these won't cause denial-of-service. If the condition is not handled,
then it may or may not cause denial-of-service.
* Accessible From Unprivileged Processes:
Determine if the bug can be reached from a typical (non-root) user process that does NOT have any special capabilities
(like CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON) or access to device nodes restricted to root.
Assume that unprivileged_bpf_disabled=1, that is eBPF loading is not accessible. However, cBPF (classical BPF)
is still accessible to non-root processes.
Assume that user namespaces are not accessible, that is, the process cannot get the mentioned capabilities even
within a new user namespace (checked by ns_capable() function in the kernel sources).
* Accessible From User Namespaces:
Determine if the bug can be reached within a user-namespace where the process has all capabilities
(including CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, CAP_PERFMON). Such capabilities are checked with ns_capable()
function in the kernel sources.
* VM Guest Trigger:
Determine if the bug can be triggered from the context of a typical KVM guest (e.g., set up by a QEMU VMM).
Consider accesses to standard Linux host paravirtualized features (virtio-blk, virtio-net, etc.),
and handling of VM exits in the KVM code.
* VM Host Trigger in The Confidetial Computing Context:
Determine if the bug can be triggered in a confidential computing guest kernel from the context of a KVM host.
Consider access to standard Linux guest paravirtualized features (virtio-blk, virtio-net, etc.).
* Ethernet Network Trigger:
Determine if the bug can be triggered by processing ingress network Ethernet traffic, either directly (network stack)
or via drivers exposed to network data.
* Other Remote Trigger:
Determine if the bug can be triggered by processing remote traffic other than Ethernet (Wifi, Bluetooth, NFC, etc).
* Peripheral Trigger:
Determine if the bug can be triggered via an untrusted peripheral device that can be physically plugged
into a system, such as a USB device or a niche hardware driver handling external hardware inputs.
This is particularly important for mobile and desktop environments where users can plug in unknown devices.
* Malicious Filesystem Trigger:
Determine if the bug can be triggered by the kernel mounting and parsing a malicious filesystem image.
This is highly critical for Desktop and Mobile environments where external media or downloaded images
might be auto-mounted.
Prefer calling several tools at the same time to save round-trips.
Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.
Prompt:
The kernel bug report is:
Kernel panic - not syncing: corrupted stack end detected inside scheduler
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G L syzkaller #0 PREEMPT
Tainted: [L]=SOFTLOCKUP
Hardware name: ARM-Versatile Express
Call trace:
[<80201a14>] (dump_backtrace) from [<80201b08>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:257)
r7:8281f940 r6:00000000 r5:822a7804 r4:00000001
[<80201af0>] (show_stack) from [<8021e458>] (__dump_stack lib/dump_stack.c:94 [inline])
[<80201af0>] (show_stack) from [<8021e458>] (dump_stack_lvl+0x5c/0x70 lib/dump_stack.c:120)
[<8021e3fc>] (dump_stack_lvl) from [<8021e484>] (dump_stack+0x18/0x1c lib/dump_stack.c:129)
r7:8281f940 r6:00000000 r5:8281b680 r4:82a80d14
[<8021e46c>] (dump_stack) from [<802025f4>] (vpanic+0x114/0x320 kernel/panic.c:650)
[<802024e0>] (vpanic) from [<80202834>] (trace_suspend_resume+0x0/0x104 kernel/panic.c:787)
r7:826cc400
[<80202800>] (panic) from [<81ae5584>] (schedule_debug kernel/sched/core.c:5855 [inline])
[<80202800>] (panic) from [<81ae5584>] (__schedule+0x13d8/0x13e0 kernel/sched/core.c:6783)
r3:57ac6e9d r2:8280001c r1:822a7804 r0:82298d68
[<81ae41ac>] (__schedule) from [<81ae57bc>] (schedule_idle+0x24/0x68 kernel/sched/core.c:7030)
r10:8281b0b4 r9:00000000 r8:00000000 r7:8280c590 r6:8281b680 r5:8280c550
r4:8281b680
[<81ae5798>] (schedule_idle) from [<802b2ee8>] (do_idle+0x17c/0x2f0 kernel/sched/idle.c:360)
r5:8280c550 r4:00000000
[<802b2d6c>] (do_idle) from [<802b336c>] (cpu_startup_entry+0x30/0x34 kernel/sched/idle.c:430)
r10:8281b0b4 r9:823d05fc r8:00000000 r7:dddf03ec r6:8280c500 r5:82822440
r4:000000ed
[<802b333c>] (cpu_startup_entry) from [<81ae2458>] (rest_init+0xdc/0xe0 init/main.c:760)
[<81ae237c>] (rest_init) from [<8260144c>] (start_kernel+0x824/0x840 init/main.c:1210)
[<82600c28>] (start_kernel) from [<00000000>] (0x0)
Rebooting in 86400 seconds..
Reply: The analysis of the bug report reveals the following sequence of events:
1. **The Panic**: The kernel panicked with `corrupted stack end detected inside scheduler`. This happens in `__schedule()` when it checks the `STACK_END_MAGIC` at the bottom of the task's stack and finds it overwritten.
2. **The Victim**: The panic occurred in `swapper/0` (PID 0), which is the idle thread. Its stack is statically allocated as `init_stack`.
3. **The Corrupted Value**: The registers dump shows `r3:57ac6e9d` (which is the expected `STACK_END_MAGIC`) and `r2:8280001c`. Given that `init_stack` is typically aligned to `THREAD_SIZE` (e.g., `0x82800000`), `0x8280001c` is an address exactly `0x1c` bytes into the stack. This strongly indicates that a stack frame pointer or saved stack pointer was pushed to the very bottom of the stack, overwriting the magic value.
4. **The Root Cause**: The kernel is tainted with `[L]=SOFTLOCKUP`. This means that prior to the panic, the CPU was stuck in a loop for at least 20 seconds, and the softlockup watchdog timer interrupt fired. When the watchdog fires, it prints a warning and calls `dump_stack()`.
5. **The Mechanism**: If the CPU was stuck in a deep call chain or a softirq handler (e.g., processing a complex network packet or malicious input), the task stack was already mostly full. The additional stack frames pushed by the watchdog's `dump_stack()` caused the stack to overflow, overwriting `init_stack[0]`. After the watchdog interrupt returned, the long loop eventually finished, and the CPU returned to the idle loop. When `do_idle()` called `__schedule()`, the corrupted magic value was detected, triggering the panic.
**Security Impact Assessment:**
* **Exploitable**: **No**. The stack overflow is a secondary effect caused by the kernel's own `dump_stack()` function pushing return addresses and frame pointers. It does not involve attacker-controlled data being written out-of-bounds, making it unexploitable for privilege escalation or arbitrary code execution.
* **Denial of Service**: **Yes**. The primary bug is a softlockup (an infinite or excessively long loop in the kernel), which halts the CPU and leads to a system crash/panic.
* **Accessible From Unprivileged Processes / User Namespaces**: **Yes**. Syzkaller runs as an unprivileged user (often within user namespaces) and was able to trigger the softlockup, indicating that no special privileges are required.
* **Specific Triggers**: Unknown. The exact subsystem (network, filesystem, etc.) where the softlockup occurred is not specified in the trace. We err on the side of caution and assume they are not specifically required.
|
| 6/2 |
2026/05/15 18:14 |
llm |
expert |
0m
Model:
Tokens:
input: 5501
output: 39
thoughts: 143
Thoughts: **Analyzing a Kernel Panic: A Deep Dive**
Okay, so I've got this bug report – a classic "Kernel panic - not syncing: corrupted stack end detected inside scheduler." Alarm bells are going off immediately. This is a serious one. Let's see... the call trace reveals a clear path to the problem: it's hitting `schedule_debug` which then triggers the panic. `schedule_debug` is called from `__schedule`, which is used by `schedule_idle`, which is then invoked by `do_idle`. This makes sense, as the kernel is essentially stuck in the idle process, which then causes problems. The call stack continues to indicate that the issue began with `cpu_startup_entry`, originating from `rest_init`, and ultimately from `start_kernel`.
The panic message explicitly says "corrupted stack end detected inside scheduler." That's the key. That tells me the stack corruption is *within* the scheduler's context. This is what I need to focus on. Time to dive into the code. I'm going straight to `kernel/sched/core.c` and looking for `schedule_debug`. I need to figure out exactly what it's checking for and how it's detecting the stack corruption. From there, I can understand how the scheduler could be corrupting the stack and work backwards to trace the root cause.
|
| 7/2 |
2026/05/15 18:15 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/sched/core.c IncludeLines:true Name:schedule_debug]
Results: map[SourceCode:5848: /*
5849: * Various schedule()-time debugging checks and statistics:
5850: */
5851: static inline void schedule_debug(struct task_struct *prev, bool preempt)
5852: {
5853: #ifdef CONFIG_SCHED_STACK_END_CHECK
5854: if (task_stack_end_corrupted(prev))
5855: panic("corrupted stack end detected inside scheduler\n");
5856:
5857: if (task_scs_end_corrupted(prev))
5858: panic("corrupted shadow stack detected inside scheduler\n");
5859: #endif
5860:
5861: #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
5862: if (!preempt && READ_ONCE(prev->__state) && prev->non_block_count) {
5863: printk(KERN_ERR "BUG: scheduling in a non-blocking section: %s/%d/%i\n",
5864: prev->comm, prev->pid, prev->non_block_count);
5865: dump_stack();
5866: add_taint(TAINT_WARN, LOCKDEP_STILL_OK);
5867: }
5868: #endif
5869:
5870: if (unlikely(in_atomic_preempt_off())) {
5871: __schedule_bug(prev);
5872: preempt_count_set(PREEMPT_DISABLED);
5873: }
5874: rcu_sleep_check();
5875: WARN_ON_ONCE(ct_state() == CT_STATE_USER);
5876:
5877: profile_hit(SCHED_PROFILING, __builtin_return_address(0));
5878:
5879: schedstat_inc(this_rq()->sched_count);
5880: }
SourceFile:kernel/sched/core.c]
|
| 8/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 6523
output: 44
thoughts: 36
Thoughts: Okay, here's my interpretation of that thought process, assuming I'm deep in the weeds of debugging kernel-level stack corruption:
**Debugging a Stack Corruption Panic**
Right, *that* feeling. The dreaded panic triggered by `task_stack_end_corrupted(prev)` has me on edge. This isn't good. Okay, breathe. The first step, as always, is to understand what actually *is* happening. I need to dive into the `task_stack_end_corrupted` function itself. What is it checking? How does it determine corruption? What could be causing the check to fail? This is where the real work begins. Let's see what that function is up to. I need to understand its logic, its assumptions, and the data it's examining to properly diagnose this.
|
| 9/2 |
2026/05/15 18:15 |
tool |
codesearch-definition-source |
0m
Error:
Args: map[ContextFile:kernel/sched/core.c IncludeLines:true Name:task_stack_end_corrupted]
Results: map[SourceCode: SourceFile:]
|
| 10/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 6798
output: 22
thoughts: 18
Thoughts: Here's my thought process, summarized as you requested:
**Debugging a Corrupted Task Stack**
Okay, so I've got this gnarly issue, a potential `task_stack_end_corrupted` error. My first instinct, and honestly, the most efficient one, is to leverage my old friend, grep. It's a lifesaver in these situations. Let's fire it up and search the codebase for that exact string. That should be the quickest way to get a handle on where this error is even mentioned, let alone where it's being triggered. From there, I can start to follow the calls, look at the error handling, and pinpoint the likely culprits within the code. Let's see what grep turns up.
|
| 11/2 |
2026/05/15 18:15 |
tool |
grepper |
0m
Args: map[Expression:task_stack_end_corrupted]
Results: map[Output:arch/powerpc/mm/fault.c=613=static void __bad_page_fault(struct pt_regs *regs, int sig)
--
arch/powerpc/mm/fault.c-650-
arch/powerpc/mm/fault.c:651: if (task_stack_end_corrupted(current))
arch/powerpc/mm/fault.c-652- printk(KERN_ALERT "Thread overran stack, or stack corrupted\n");
--
arch/x86/mm/fault.c=639=page_fault_oops(struct pt_regs *regs, unsigned long error_code,
--
arch/x86/mm/fault.c-704-
arch/x86/mm/fault.c:705: if (task_stack_end_corrupted(current))
arch/x86/mm/fault.c-706- printk(KERN_EMERG "Thread overran stack, or stack corrupted\n");
--
include/linux/sched/task_stack.h=84=void exit_task_stack_account(struct task_struct *tsk);
include/linux/sched/task_stack.h-85-
include/linux/sched/task_stack.h:86:#define task_stack_end_corrupted(task) \
include/linux/sched/task_stack.h-87- (*(end_of_stack(task)) != STACK_END_MAGIC)
--
kernel/sched/core.c=5851=static inline void schedule_debug(struct task_struct *prev, bool preempt)
--
kernel/sched/core.c-5853-#ifdef CONFIG_SCHED_STACK_END_CHECK
kernel/sched/core.c:5854: if (task_stack_end_corrupted(prev))
kernel/sched/core.c-5855- panic("corrupted stack end detected inside scheduler\n");
--
kernel/sched/core.c=8838=void __might_resched(const char *file, int line, unsigned int offsets)
--
kernel/sched/core.c-8873-
kernel/sched/core.c:8874: if (task_stack_end_corrupted(current))
kernel/sched/core.c-8875- pr_emerg("Thread overran stack, or stack corrupted\n");
--
kernel/trace/trace_stack.c=155=static void check_stack(unsigned long ip, unsigned long *stack)
--
kernel/trace/trace_stack.c-275-
kernel/trace/trace_stack.c:276: if (task_stack_end_corrupted(current)) {
kernel/trace/trace_stack.c-277- print_max_stack();
]
|
| 12/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 7688
output: 19
thoughts: 218
Thoughts: **Analyzing a Corrupted Idle Thread Stack**
Okay, so the macro `task_stack_end_corrupted(task)` is flagging an issue. Specifically, the stack end of a task is not holding the expected `STACK_END_MAGIC` value. This is interesting. The system panicked in `swapper/0`, the idle thread, which immediately jumps out to me as odd. The panic occurred either during boot or shortly after, given the reboot timer. The call trace, `start_kernel` down to `schedule_debug`, points directly to the initial task's stack being the culprit.
The question is, why would the idle thread's stack be corrupted? It's the most fundamental task, running almost immediately. My initial thought is a hardware issue, especially since we are using ARM Versatile Express. Is this a known bug in this environment, or maybe a configuration issue specific to our setup? It is worth checking for any known issues with `STACK_END_MAGIC` itself on ARM; perhaps there are documented corner cases, alignment issues, or memory corruption scenarios specific to this platform. I need to dig into the kernel configuration and the hardware setup to see if anything jumps out. This is a critical problem, we can't be sure of anything if the idle task's stack is corrupted.
|
| 13/2 |
2026/05/15 18:15 |
tool |
grepper |
0m
Args: map[Expression:STACK_END_MAGIC]
Results: map[Output:arch/powerpc/include/asm/livepatch.h=14=static inline void klp_init_thread_info(struct task_struct *p)
arch/powerpc/include/asm/livepatch.h-15-{
arch/powerpc/include/asm/livepatch.h:16: /* + 1 to account for STACK_END_MAGIC */
arch/powerpc/include/asm/livepatch.h-17- task_thread_info(p)->livepatch_sp = end_of_stack(p) + 1;
--
arch/powerpc/kernel/head_8xx.S=513=start_here:
--
arch/powerpc/kernel/head_8xx.S-525- addi r1,r1,init_thread_union@l
arch/powerpc/kernel/head_8xx.S:526: lis r0, STACK_END_MAGIC@h
arch/powerpc/kernel/head_8xx.S:527: ori r0, r0, STACK_END_MAGIC@l
arch/powerpc/kernel/head_8xx.S-528- stw r0, 0(r1)
--
arch/powerpc/kernel/trace/ftrace_entry.S=340=livepatch_handler:
--
arch/powerpc/kernel/trace/ftrace_entry.S-348- /* Store stack end marker */
arch/powerpc/kernel/trace/ftrace_entry.S:349: lis r12, STACK_END_MAGIC@h
arch/powerpc/kernel/trace/ftrace_entry.S:350: ori r12, r12, STACK_END_MAGIC@l
arch/powerpc/kernel/trace/ftrace_entry.S-351- std r12, -8(r11)
--
arch/powerpc/kernel/trace/ftrace_entry.S-377- /* Check stack marker hasn't been trashed */
arch/powerpc/kernel/trace/ftrace_entry.S:378: lis r2, STACK_END_MAGIC@h
arch/powerpc/kernel/trace/ftrace_entry.S:379: ori r2, r2, STACK_END_MAGIC@l
arch/powerpc/kernel/trace/ftrace_entry.S-380- ld r12, -8(r11)
--
drivers/misc/lkdtm/kstack_erase.c=28=static void noinstr check_stackleak_irqoff(void)
--
drivers/misc/lkdtm/kstack_erase.c-42- * fail unless the boundaries are incorrect or we're clobbering the
drivers/misc/lkdtm/kstack_erase.c:43: * STACK_END_MAGIC, and in either casee something is seriously wrong.
drivers/misc/lkdtm/kstack_erase.c-44- */
--
include/linux/kstack_erase.h=23=stackleak_task_low_bound(const struct task_struct *tsk)
--
include/linux/kstack_erase.h-25- /*
include/linux/kstack_erase.h:26: * The lowest unsigned long on the task stack contains STACK_END_MAGIC,
include/linux/kstack_erase.h-27- * which we must not corrupt.
--
include/linux/sched/task_stack.h=84=void exit_task_stack_account(struct task_struct *tsk);
--
include/linux/sched/task_stack.h-86-#define task_stack_end_corrupted(task) \
include/linux/sched/task_stack.h:87: (*(end_of_stack(task)) != STACK_END_MAGIC)
include/linux/sched/task_stack.h-88-
--
include/uapi/linux/magic.h-74-
include/uapi/linux/magic.h:75:#define STACK_END_MAGIC 0x57AC6E9D
include/uapi/linux/magic.h-76-
--
kernel/fork.c=901=void set_task_stack_end_magic(struct task_struct *tsk)
--
kernel/fork.c-905- stackend = end_of_stack(tsk);
kernel/fork.c:906: *stackend = STACK_END_MAGIC; /* for overflow detection */
kernel/fork.c-907-}
]
|
| 14/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 9334
output: 19
thoughts: 424
Thoughts: **Debugging a Kernel Panic: Stack Corruption Mystery**
Okay, so I'm looking at this kernel panic trace, and the first thing that jumps out is that `STACK_END_MAGIC` is `0x57AC6E9D`. Then I see this in the panic: `r3:57ac6e9d`. Hmm, that's interesting because `r3` *is* `STACK_END_MAGIC`.
The panic happened during `__schedule`, so I should probably dig into the scheduling code. Wait a minute, I remember that `schedule_debug` is inlined into `__schedule`, so I can trace that too. The panic is triggered by `task_stack_end_corrupted(prev)`. And `prev` is `swapper/0`. Now I'm wondering, why would `*(end_of_stack(prev))` not equal `STACK_END_MAGIC`?
Hold on... if `r3` *is* `57ac6e9d`, did the code even compare the read value with `STACK_END_MAGIC`? Maybe the comparison failed? No, wait... if `r3` contains `STACK_END_MAGIC` that means the comparison would have succeeded if read correctly. But if it's correct, why the panic? I'm getting confused.
Or, is `r3` the *read* value, and it *is* being compared to `STACK_END_MAGIC`, and the read value is what's different? But `STACK_END_MAGIC` *is* `0x57AC6E9D`, and if `r3` *is* `57ac6e9d`, then it *matches*! This doesn't make sense...
Ah, if the panic is occurring even when `r3` *matches* `STACK_END_MAGIC`, then something else is wrong. I need to look closer at `end_of_stack` for ARM. Let's see how that works...
|
| 15/2 |
2026/05/15 18:15 |
tool |
grepper |
0m
Args: map[Expression:end_of_stack]
Results: map[Output:arch/arm/kernel/traps.c=218=void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
--
arch/arm/kernel/traps.c-245- ok = 0;
arch/arm/kernel/traps.c:246: } else if (fp < (unsigned long)end_of_stack(tsk))
arch/arm/kernel/traps.c-247- pr_cont("frame pointer underflow");
--
arch/arm/kernel/traps.c=272=static int __die(const char *str, int err, struct pt_regs *regs)
--
arch/arm/kernel/traps.c-289- pr_emerg("Process %.*s (pid: %d, stack limit = 0x%p)\n",
arch/arm/kernel/traps.c:290: TASK_COMM_LEN, tsk->comm, task_pid_nr(tsk), end_of_stack(tsk));
arch/arm/kernel/traps.c-291-
--
arch/powerpc/include/asm/livepatch.h=14=static inline void klp_init_thread_info(struct task_struct *p)
--
arch/powerpc/include/asm/livepatch.h-16- /* + 1 to account for STACK_END_MAGIC */
arch/powerpc/include/asm/livepatch.h:17: task_thread_info(p)->livepatch_sp = end_of_stack(p) + 1;
arch/powerpc/include/asm/livepatch.h-18-}
--
drivers/md/dm-vdo/indexer/radix-sort.c=56=struct radix_sorter {
--
drivers/md/dm-vdo/indexer/radix-sort.c-59- sort_key_t *pile[256];
drivers/md/dm-vdo/indexer/radix-sort.c:60: struct task *end_of_stack;
drivers/md/dm-vdo/indexer/radix-sort.c-61- struct task insertion_list[256];
--
drivers/md/dm-vdo/indexer/radix-sort.c=122=static inline void measure_bins(const struct task task, struct histogram *bins)
--
drivers/md/dm-vdo/indexer/radix-sort.c-161- * @stack: pointer the top of the stack
drivers/md/dm-vdo/indexer/radix-sort.c:162: * @end_of_stack: the end of the stack
drivers/md/dm-vdo/indexer/radix-sort.c-163- * @list: pointer the head of the list
--
drivers/md/dm-vdo/indexer/radix-sort.c-171- */
drivers/md/dm-vdo/indexer/radix-sort.c:172:static inline int push_bins(struct task **stack, struct task *end_of_stack,
drivers/md/dm-vdo/indexer/radix-sort.c-173- struct task **list, sort_key_t *pile[],
--
drivers/md/dm-vdo/indexer/radix-sort.c-189- if (size > INSERTION_SORT_THRESHOLD) {
drivers/md/dm-vdo/indexer/radix-sort.c:190: if (*stack >= end_of_stack)
drivers/md/dm-vdo/indexer/radix-sort.c-191- return UDS_BAD_STATE;
--
drivers/md/dm-vdo/indexer/radix-sort.c=208=int uds_make_radix_sorter(unsigned int count, struct radix_sorter **sorter)
--
drivers/md/dm-vdo/indexer/radix-sort.c-219- radix_sorter->count = count;
drivers/md/dm-vdo/indexer/radix-sort.c:220: radix_sorter->end_of_stack = radix_sorter->stack + stack_size;
drivers/md/dm-vdo/indexer/radix-sort.c-221- *sorter = radix_sorter;
--
drivers/md/dm-vdo/indexer/radix-sort.c=234=int uds_radix_sort(struct radix_sorter *sorter, const unsigned char *keys[],
--
drivers/md/dm-vdo/indexer/radix-sort.c-281- insertion_task_list = sorter->insertion_list;
drivers/md/dm-vdo/indexer/radix-sort.c:282: result = push_bins(&task_stack, sorter->end_of_stack,
drivers/md/dm-vdo/indexer/radix-sort.c-283- &insertion_task_list, pile, bins, task.first_key,
--
include/linux/kstack_erase.h=23=stackleak_task_low_bound(const struct task_struct *tsk)
--
include/linux/kstack_erase.h-28- */
include/linux/kstack_erase.h:29: return (unsigned long)end_of_stack(tsk) + sizeof(unsigned long);
include/linux/kstack_erase.h-30-}
--
include/linux/sched/task_stack.h=21=static __always_inline void *task_stack_page(const struct task_struct *task)
--
include/linux/sched/task_stack.h-27-
include/linux/sched/task_stack.h:28:static __always_inline unsigned long *end_of_stack(const struct task_struct *task)
include/linux/sched/task_stack.h-29-{
--
include/linux/sched/task_stack.h=41=static inline void setup_thread_stack(struct task_struct *p, struct task_struct *org)
--
include/linux/sched/task_stack.h-55- */
include/linux/sched/task_stack.h:56:static inline unsigned long *end_of_stack(const struct task_struct *p)
include/linux/sched/task_stack.h-57-{
--
include/linux/sched/task_stack.h=84=void exit_task_stack_account(struct task_struct *tsk);
--
include/linux/sched/task_stack.h-86-#define task_stack_end_corrupted(task) \
include/linux/sched/task_stack.h:87: (*(end_of_stack(task)) != STACK_END_MAGIC)
include/linux/sched/task_stack.h-88-
--
kernel/exit.c=783=unsigned long stack_not_used(struct task_struct *p)
kernel/exit.c-784-{
kernel/exit.c:785: unsigned long *n = end_of_stack(p);
kernel/exit.c-786-
--
kernel/exit.c-790-
kernel/exit.c:791: return (unsigned long)end_of_stack(p) - (unsigned long)n;
kernel/exit.c-792-}
--
kernel/exit.c=794=unsigned long stack_not_used(struct task_struct *p)
kernel/exit.c-795-{
kernel/exit.c:796: unsigned long *n = end_of_stack(p);
kernel/exit.c-797-
--
kernel/exit.c-801-
kernel/exit.c:802: return (unsigned long)n - (unsigned long)end_of_stack(p);
kernel/exit.c-803-}
--
kernel/fork.c=901=void set_task_stack_end_magic(struct task_struct *tsk)
--
kernel/fork.c-904-
kernel/fork.c:905: stackend = end_of_stack(tsk);
kernel/fork.c-906- *stackend = STACK_END_MAGIC; /* for overflow detection */
--
mm/kasan/report_generic.c=293=static bool __must_check get_address_stack_frame_info(const void *addr,
--
mm/kasan/report_generic.c-308- shadow_ptr = kasan_mem_to_shadow((void *)aligned_addr);
mm/kasan/report_generic.c:309: shadow_bottom = kasan_mem_to_shadow(end_of_stack(current));
mm/kasan/report_generic.c-310-
]
|
| 16/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 12374
output: 45
thoughts: 40
Thoughts: **Examining the Task Stack Definition**
Okay, hold on a second. I need to refresh my memory about where that `end_of_stack` symbol lives. Ah, yes, it's defined in `include/linux/sched/task_stack.h`. That's right, it makes sense it would be in a header related to task scheduling and the stack. Now, let's just quickly go and check the definition of `end_of_stack` to ensure I'm remembering its purpose correctly, and refresh my mental model of how it functions in the system. I need to be absolutely certain I understand its exact role within the scheduler's context.
|
| 17/2 |
2026/05/15 18:15 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/sched/task_stack.h IncludeLines:true Name:end_of_stack]
Results: map[SourceCode: 28: static __always_inline unsigned long *end_of_stack(const struct task_struct *task)
29: {
30: #ifdef CONFIG_STACK_GROWSUP
31: return (unsigned long *)((unsigned long)task->stack + THREAD_SIZE) - 1;
32: #else
33: return task->stack;
34: #endif
35: }
SourceFile:include/linux/sched/task_stack.h]
|
| 18/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 12746
output: 45
thoughts: 23
Thoughts: Here's the summary, framed as your own thoughts:
**Dissecting This Stack Pointer**
Okay, so I'm looking at this code and trying to grasp how the stack is being managed. Right, `end_of_stack` is being defined as `task->stack`. That seems straightforward enough, at least initially. I'm assuming `task->stack` is a pointer to the current top of the stack or the end of the stack, in memory, for this particular task.
Wait a second, though... I need to backtrack, because I'm seeing another definition kicking around. There's clearly another consideration I'm missing here, and I've got to sort that out. I need to figure out how these two definitions play together, or more likely, how they're *differing*. Something's not quite lining up, and that means my assumptions need refining.
|
| 19/2 |
2026/05/15 18:15 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:include/linux/sched/task_stack.h IncludeLines:true Name:end_of_stack]
Results: map[SourceCode: 28: static __always_inline unsigned long *end_of_stack(const struct task_struct *task)
29: {
30: #ifdef CONFIG_STACK_GROWSUP
31: return (unsigned long *)((unsigned long)task->stack + THREAD_SIZE) - 1;
32: #else
33: return task->stack;
34: #endif
35: }
SourceFile:include/linux/sched/task_stack.h]
|
| 20/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 13149
output: 24
thoughts: 63
Thoughts: Okay, let me break this down.
**Diving into the Stack's End**
Alright, the `grep` output just flagged something interesting on lines 56-57: `static inline unsigned long *end_of_stack(const struct task_struct *p)`. That function name looks familiar, and it's pointing me directly towards stack management within the kernel's scheduling. So, I need to get my head around this. Let's pull up `include/linux/sched/task_stack.h` and focus on lines 40-60. I know this section is likely to contain the crucial definitions related to how the end of the stack is determined for a given task. This should clarify how the kernel actually calculates and uses that address. I expect I'll see the pointer manipulation required to determine where the stack ends.
|
| 21/2 |
2026/05/15 18:15 |
tool |
grepper |
0m
Args: map[Expression:static inline unsigned long \*end_of_stack]
Results: map[Output:include/linux/sched/task_stack.h=41=static inline void setup_thread_stack(struct task_struct *p, struct task_struct *org)
--
include/linux/sched/task_stack.h-55- */
include/linux/sched/task_stack.h:56:static inline unsigned long *end_of_stack(const struct task_struct *p)
include/linux/sched/task_stack.h-57-{
]
|
| 22/2 |
2026/05/15 18:15 |
llm |
expert |
0m
Model:
Tokens:
input: 13538
output: 26
thoughts: 23
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Diving into task_stack.h**
Alright, let's get down to brass tacks. I need to refresh my understanding of the stack layout within the kernel's task structure, and the second definition is what I'm interested in, specifically. I'm going to pull up `include/linux/sched/task_stack.h` to see exactly how things are defined in the latest version. Time to crack open that header file and get to the heart of the matter. I expect to find a precise description of the stack's organization, probably using `struct` and potentially some macro trickery, along with related macros. I'll be looking for nuances in how the stack grows, alignment considerations, and any architecture-specific aspects that are relevant here. Let's see what we've got.
|
| 23/2 |
2026/05/15 18:16 |
tool |
read-file |
0m
Args: map[File:include/linux/sched/task_stack.h]
Results: map[Contents:/* SPDX-License-Identifier: GPL-2.0 */
#ifndef _LINUX_SCHED_TASK_STACK_H
#define _LINUX_SCHED_TASK_STACK_H
/*
* task->stack (kernel stack) handling interfaces:
*/
#include <linux/sched.h>
#include <linux/magic.h>
#include <linux/refcount.h>
#include <linux/kasan.h>
#ifdef CONFIG_THREAD_INFO_IN_TASK
/*
* When accessing the stack of a non-current task that might exit, use
* try_get_task_stack() instead. task_stack_page will return a pointer
* that could get freed out from under you.
*/
static __always_inline void *task_stack_page(const struct task_struct *task)
{
return task->stack;
}
#define setup_thread_stack(new,old) do { } while(0)
static __always_inline unsigned long *end_of_stack(const struct task_struct *task)
{
#ifdef CONFIG_STACK_GROWSUP
return (unsigned long *)((unsigned long)task->stack + THREAD_SIZE) - 1;
#else
return task->stack;
#endif
}
#else
#define task_stack_page(task) ((void *)(task)->stack)
static inline void setup_thread_stack(struct task_struct *p, struct task_struct *org)
{
*task_thread_info(p) = *task_thread_info(org);
task_thread_info(p)->task = p;
}
/*
* Return the address of the last usable long on the stack.
*
* When the stack grows down, this is just above the thread
* info struct. Going any lower will corrupt the threadinfo.
*
* When the stack grows up, this is the highest address.
* Beyond that position, we corrupt data on the next page.
*/
static inline unsigned long *end_of_stack(const struct task_struct *p)
{
#ifdef CONFIG_STACK_GROWSUP
return (unsigned long *)((unsigned long)task_thread_info(p) + THREAD_SIZE) - 1;
#else
return (unsigned long *)(task_thread_info(p) + 1);
#endif
}
#endif
#ifdef CONFIG_THREAD_INFO_IN_TASK
static inline void *try_get_task_stack(struct task_struct *tsk)
{
return refcount_inc_not_zero(&tsk->stack_refcount) ?
task_stack_page(tsk) : NULL;
}
extern void put_task_stack(struct task_struct *tsk);
#else
static inline void *try_get_task_stack(struct task_struct *tsk)
{
return task_stack_page(tsk);
}
static inline void put_task_stack(struct task_struct *tsk) {}
#endif
void exit_task_stack_account(struct task_struct *tsk);
#define task_stack_end_corrupted(task) \
(*(end_of_stack(task)) != STACK_END_MAGIC)
static inline int object_is_on_stack(const void *obj)
{
void *stack = task_stack_page(current);
obj = kasan_reset_tag(obj);
return (obj >= stack) && (obj < (stack + THREAD_SIZE));
}
extern void thread_stack_cache_init(void);
#ifdef CONFIG_DEBUG_STACK_USAGE
unsigned long stack_not_used(struct task_struct *p);
#else
static inline unsigned long stack_not_used(struct task_struct *p)
{
return 0;
}
#endif
extern void set_task_stack_end_magic(struct task_struct *tsk);
static inline int kstack_end(void *addr)
{
/* Reliable end of stack detection:
* Some APM bios versions misalign the stack
*/
return !(((unsigned long)addr+sizeof(void*)-1) & (THREAD_SIZE-sizeof(void*)));
}
#endif /* _LINUX_SCHED_TASK_STACK_H */
]
|
| 24/2 |
2026/05/15 18:16 |
llm |
expert |
0m
Model:
Tokens:
input: 14782
output: 23
thoughts: 70
Thoughts: Okay, let's break this down.
**Understanding Thread Information and Memory Layout**
Right, so I'm looking at this code and trying to grasp how thread information is accessed, particularly in relation to the stack. If `CONFIG_THREAD_INFO_IN_TASK` is *not* defined, then `end_of_stack` is essentially calculated as `(unsigned long *)(task_thread_info(p) + 1)`. I get that; it's pointing to the end of the stack, likely. The "+ 1" suggests some kind of pointer arithmetic, moving past the thread info structure itself, to get to the very end of that stack.
Now, a red flag is going up. I seem to recall that ARM architectures often handle thread information differently. My memory is fuzzy here, but I have a feeling that we might be dealing with a configuration where `CONFIG_THREAD_INFO_IN_TASK` *isn't* typical for ARM. I'm going to double-check that assumption; it's essential for how to interpret this line of code. Gotta make sure the code matches the architecture I'm working with.
|
| 25/2 |
2026/05/15 18:16 |
tool |
grepper |
0m
Args: map[Expression:CONFIG_THREAD_INFO_IN_TASK]
Results: map[Output:Documentation/process/deprecated.rst=196=lead to a crash, possible overwriting sensitive contents at the end of the
Documentation/process/deprecated.rst:197:stack (when built without `CONFIG_THREAD_INFO_IN_TASK=y`), or overwriting
Documentation/process/deprecated.rst-198-memory adjacent to the stack (when built without `CONFIG_VMAP_STACK=y`)
--
Documentation/translations/it_IT/process/deprecated.rst=215=dati importanti alla fine dello stack (quando il kernel è compilato senza
Documentation/translations/it_IT/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente
Documentation/translations/it_IT/process/deprecated.rst-217-allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`).
--
Documentation/translations/sp_SP/process/deprecated.rst=215=de contenido al final de la pila (cuando se construye sin
Documentation/translations/sp_SP/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente
Documentation/translations/sp_SP/process/deprecated.rst-217-a la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`).
--
arch/arm/kernel/entry-armv.S=512=ENTRY(__switch_to)
--
arch/arm/kernel/entry-armv.S-573-
arch/arm/kernel/entry-armv.S:574: @ When CONFIG_THREAD_INFO_IN_TASK=n, the update of SP itself is what
arch/arm/kernel/entry-armv.S-575- @ effectuates the task switch, as that is what causes the observable
arch/arm/kernel/entry-armv.S-576- @ values of current and current_thread_info to change. When
arch/arm/kernel/entry-armv.S:577: @ CONFIG_THREAD_INFO_IN_TASK=y, setting current (and therefore
arch/arm/kernel/entry-armv.S-578- @ current_thread_info) is done explicitly, and the update of SP just
--
include/linux/sched.h=819=struct task_struct {
include/linux/sched.h:820:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-821- /*
--
include/linux/sched.h-1566-#endif
include/linux/sched.h:1567:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1568- /* A live task holds one reference: */
--
include/linux/sched.h=1949=union thread_union {
include/linux/sched.h-1950- struct task_struct task;
include/linux/sched.h:1951:#ifndef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1952- struct thread_info thread_info;
--
include/linux/sched.h-1956-
include/linux/sched.h:1957:#ifndef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1958-extern struct thread_info init_thread_info;
--
include/linux/sched.h=1961=extern unsigned long init_stack[THREAD_SIZE / sizeof(unsigned long)];
include/linux/sched.h-1962-
include/linux/sched.h:1963:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1964-# define task_thread_info(task) (&(task)->thread_info)
--
include/linux/sched/task_stack.h-13-
include/linux/sched/task_stack.h:14:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched/task_stack.h-15-
--
include/linux/sched/task_stack.h=56=static inline unsigned long *end_of_stack(const struct task_struct *p)
--
include/linux/sched/task_stack.h-66-
include/linux/sched/task_stack.h:67:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched/task_stack.h-68-static inline void *try_get_task_stack(struct task_struct *tsk)
--
include/linux/thread_info.h-16-
include/linux/thread_info.h:17:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/thread_info.h-18-/*
include/linux/thread_info.h:19: * For CONFIG_THREAD_INFO_IN_TASK kernels we need <asm/current.h> for the
include/linux/thread_info.h:20: * definition of current, but for !CONFIG_THREAD_INFO_IN_TASK kernels,
include/linux/thread_info.h-21- * including <asm/current.h> can cause a circular dependency on some platforms.
--
init/init_task.c=96=struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
init/init_task.c:97:#ifdef CONFIG_THREAD_INFO_IN_TASK
init/init_task.c-98- .thread_info = INIT_THREAD_INFO(init_task),
--
init/init_task.c=253=EXPORT_SYMBOL(init_task);
--
init/init_task.c-258- */
init/init_task.c:259:#ifndef CONFIG_THREAD_INFO_IN_TASK
init/init_task.c-260-struct thread_info init_thread_info __init_thread_info = INIT_THREAD_INFO(init_task);
--
kernel/fork.c=513=static void release_task_stack(struct task_struct *tsk)
--
kernel/fork.c-520-
kernel/fork.c:521:#ifdef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-522-void put_task_stack(struct task_struct *tsk)
--
kernel/fork.c=529=void free_task(struct task_struct *tsk)
--
kernel/fork.c-536-
kernel/fork.c:537:#ifndef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-538- /*
--
kernel/fork.c=909=static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
--
kernel/fork.c-927-
kernel/fork.c:928:#ifdef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-929- refcount_set(&tsk->stack_refcount, 1);
]
|
| 26/2 |
2026/05/15 18:16 |
llm |
expert |
0m
Model:
Tokens:
input: 16833
output: 21
thoughts: 100
Thoughts: **Investigating ARM Thread Info Location**
Okay, so I'm diving into this ARM architecture code, and I'm trying to figure out how the kernel determines the end of the stack for a given task. I seem to recall that ARM supports `CONFIG_THREAD_INFO_IN_TASK`, but I'm not sure if it's actually enabled in this specific configuration. I need to make sure that the option is either enabled or disabled and understand its effects.
Aha, wait a minute, if `CONFIG_THREAD_INFO_IN_TASK` *isn't* defined, then `end_of_stack` is calculated as `(unsigned long *)(task_thread_info(p) + 1)`. That's the crucial detail I needed to remember. This strongly suggests that I need to check how the thread info structure is being placed and what the implications of the configuration are.
Right, time to go directly to the source. I'm going to quickly check `arch/arm/Kconfig` to see if `THREAD_INFO_IN_TASK` is explicitly selected or not. That will clarify how thread information is stored on the stack and allow me to understand how `end_of_stack` is calculated. It's all about verifying the configuration options here.
|
| 27/2 |
2026/05/15 18:16 |
tool |
grepper |
0m
Args: map[Expression:THREAD_INFO_IN_TASK]
Results: map[Output:Documentation/features/core/thread-info-in-task/arch-support.txt-2-# Feature name: thread-info-in-task
Documentation/features/core/thread-info-in-task/arch-support.txt:3:# Kconfig: THREAD_INFO_IN_TASK
Documentation/features/core/thread-info-in-task/arch-support.txt-4-# description: arch makes use of the core kernel facility to embed thread_info in task_struct
--
Documentation/mm/vmalloced-kernel-stacks.rst=143=Conclusions
--
Documentation/mm/vmalloced-kernel-stacks.rst-147- high-order stack allocation, at least when the cache hits.
Documentation/mm/vmalloced-kernel-stacks.rst:148:- THREAD_INFO_IN_TASK gets rid of arch-specific thread_info entirely and
Documentation/mm/vmalloced-kernel-stacks.rst-149- simply embed the thread_info (containing only flags) and 'int cpu' into
--
Documentation/process/deprecated.rst=196=lead to a crash, possible overwriting sensitive contents at the end of the
Documentation/process/deprecated.rst:197:stack (when built without `CONFIG_THREAD_INFO_IN_TASK=y`), or overwriting
Documentation/process/deprecated.rst-198-memory adjacent to the stack (when built without `CONFIG_VMAP_STACK=y`)
--
Documentation/translations/it_IT/process/deprecated.rst=215=dati importanti alla fine dello stack (quando il kernel è compilato senza
Documentation/translations/it_IT/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente
Documentation/translations/it_IT/process/deprecated.rst-217-allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`).
--
Documentation/translations/sp_SP/process/deprecated.rst=215=de contenido al final de la pila (cuando se construye sin
Documentation/translations/sp_SP/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente
Documentation/translations/sp_SP/process/deprecated.rst-217-a la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`).
--
Documentation/translations/zh_CN/mm/vmalloced-kernel-stacks.rst=100=task_struct中的stack_vm_area指针可以跟踪虚拟分配的堆栈，一个非空的stack_vm_area
--
Documentation/translations/zh_CN/mm/vmalloced-kernel-stacks.rst-129-- vmalloced堆栈的percpu缓存似乎比高阶堆栈分配要快一些，至少在缓存命中时是这样。
Documentation/translations/zh_CN/mm/vmalloced-kernel-stacks.rst:130:- THREAD_INFO_IN_TASK完全摆脱了arch-specific thread_info，并简单地将
Documentation/translations/zh_CN/mm/vmalloced-kernel-stacks.rst-131- thread_info（仅包含标志）和'int cpu'嵌入task_struct中。
--
arch/arm/Kconfig=2=config ARM
--
arch/arm/Kconfig-156- select SYS_SUPPORTS_APM_EMULATION
arch/arm/Kconfig:157: select THREAD_INFO_IN_TASK
arch/arm/Kconfig-158- select TIMER_OF if OF
--
arch/arm/kernel/entry-armv.S=512=ENTRY(__switch_to)
--
arch/arm/kernel/entry-armv.S-573-
arch/arm/kernel/entry-armv.S:574: @ When CONFIG_THREAD_INFO_IN_TASK=n, the update of SP itself is what
arch/arm/kernel/entry-armv.S-575- @ effectuates the task switch, as that is what causes the observable
arch/arm/kernel/entry-armv.S-576- @ values of current and current_thread_info to change. When
arch/arm/kernel/entry-armv.S:577: @ CONFIG_THREAD_INFO_IN_TASK=y, setting current (and therefore
arch/arm/kernel/entry-armv.S-578- @ current_thread_info) is done explicitly, and the update of SP just
--
arch/arm64/Kconfig=2=config ARM64
--
arch/arm64/Kconfig-278- select SYSCTL_EXCEPTION_TRACE
arch/arm64/Kconfig:279: select THREAD_INFO_IN_TASK
arch/arm64/Kconfig-280- select HAVE_ARCH_USERFAULTFD_MINOR if USERFAULTFD
--
arch/parisc/Kconfig=2=config PARISC
--
arch/parisc/Kconfig-80- select CPU_NO_EFFICIENT_FFS
arch/parisc/Kconfig:81: select THREAD_INFO_IN_TASK
arch/parisc/Kconfig-82- select MMU_GATHER_RCU_TABLE_FREE
--
arch/powerpc/Kconfig=118=config PPC
--
arch/powerpc/Kconfig-327- select SYSCTL_EXCEPTION_TRACE
arch/powerpc/Kconfig:328: select THREAD_INFO_IN_TASK
arch/powerpc/Kconfig-329- select TRACE_IRQFLAGS_SUPPORT
--
arch/riscv/Kconfig=13=config RISCV
--
arch/riscv/Kconfig-224- select SYSCTL_EXCEPTION_TRACE
arch/riscv/Kconfig:225: select THREAD_INFO_IN_TASK
arch/riscv/Kconfig-226- select TRACE_IRQFLAGS_SUPPORT
--
arch/riscv/include/asm/smp.h=58=asmlinkage void smp_callin(void);
--
arch/riscv/include/asm/smp.h-61- * Obtains the hart ID of the currently executing task. This relies on
arch/riscv/include/asm/smp.h:62: * THREAD_INFO_IN_TASK, but we define that unconditionally.
arch/riscv/include/asm/smp.h-63- */
--
arch/s390/Kconfig=78=config S390
--
arch/s390/Kconfig-282- select SYSTEM_DATA_VERIFICATION if KEXEC_SIG
arch/s390/Kconfig:283: select THREAD_INFO_IN_TASK
arch/s390/Kconfig-284- select TRACE_IRQFLAGS_SUPPORT
--
arch/um/Kconfig=5=config UML
--
arch/um/Kconfig-42- select HAVE_SYSCALL_TRACEPOINTS
arch/um/Kconfig:43: select THREAD_INFO_IN_TASK
arch/um/Kconfig-44- select SPARSE_IRQ
--
arch/x86/Kconfig=58=config X86
--
arch/x86/Kconfig-322- select SYSCTL_EXCEPTION_TRACE
arch/x86/Kconfig:323: select THREAD_INFO_IN_TASK
arch/x86/Kconfig-324- select TRACE_IRQFLAGS_SUPPORT
--
include/linux/sched.h=819=struct task_struct {
include/linux/sched.h:820:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-821- /*
--
include/linux/sched.h-1566-#endif
include/linux/sched.h:1567:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1568- /* A live task holds one reference: */
--
include/linux/sched.h=1949=union thread_union {
include/linux/sched.h-1950- struct task_struct task;
include/linux/sched.h:1951:#ifndef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1952- struct thread_info thread_info;
--
include/linux/sched.h-1956-
include/linux/sched.h:1957:#ifndef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1958-extern struct thread_info init_thread_info;
--
include/linux/sched.h=1961=extern unsigned long init_stack[THREAD_SIZE / sizeof(unsigned long)];
include/linux/sched.h-1962-
include/linux/sched.h:1963:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1964-# define task_thread_info(task) (&(task)->thread_info)
--
include/linux/sched/task_stack.h-13-
include/linux/sched/task_stack.h:14:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched/task_stack.h-15-
--
include/linux/sched/task_stack.h=56=static inline unsigned long *end_of_stack(const struct task_struct *p)
--
include/linux/sched/task_stack.h-66-
include/linux/sched/task_stack.h:67:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched/task_stack.h-68-static inline void *try_get_task_stack(struct task_struct *tsk)
--
include/linux/thread_info.h-16-
include/linux/thread_info.h:17:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/thread_info.h-18-/*
include/linux/thread_info.h:19: * For CONFIG_THREAD_INFO_IN_TASK kernels we need <asm/current.h> for the
include/linux/thread_info.h:20: * definition of current, but for !CONFIG_THREAD_INFO_IN_TASK kernels,
include/linux/thread_info.h-21- * including <asm/current.h> can cause a circular dependency on some platforms.
--
init/Kconfig=194=config BUILDTIME_TABLE_SORT
--
init/Kconfig-196-
init/Kconfig:197:config THREAD_INFO_IN_TASK
init/Kconfig-198- bool
--
init/init_task.c=96=struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
init/init_task.c:97:#ifdef CONFIG_THREAD_INFO_IN_TASK
init/init_task.c-98- .thread_info = INIT_THREAD_INFO(init_task),
--
init/init_task.c=253=EXPORT_SYMBOL(init_task);
--
init/init_task.c-258- */
init/init_task.c:259:#ifndef CONFIG_THREAD_INFO_IN_TASK
init/init_task.c-260-struct thread_info init_thread_info __init_thread_info = INIT_THREAD_INFO(init_task);
--
kernel/fork.c=513=static void release_task_stack(struct task_struct *tsk)
--
kernel/fork.c-520-
kernel/fork.c:521:#ifdef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-522-void put_task_stack(struct task_struct *tsk)
--
kernel/fork.c=529=void free_task(struct task_struct *tsk)
--
kernel/fork.c-536-
kernel/fork.c:537:#ifndef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-538- /*
--
kernel/fork.c=909=static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
--
kernel/fork.c-927-
kernel/fork.c:928:#ifdef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-929- refcount_set(&tsk->stack_refcount, 1);
]
|
| 28/2 |
2026/05/15 18:16 |
llm |
expert |
0m
Model:
Tokens:
input: 20273
output: 38
thoughts: 241
Thoughts: **Debugging a Corrupted Stack End**
Okay, so the ARM architecture is using `THREAD_INFO_IN_TASK` for stack management. This means `end_of_stack` is essentially the same as `task->stack`. But hold on, isn't `task->stack` supposed to point to the *bottom* of the stack, the lowest memory address? And we're writing `STACK_END_MAGIC` to `*task->stack` as a canary value. If `task_stack_end_corrupted(prev)` returns true, it's because `*(unsigned long *)(task->stack)` doesn't equal `STACK_END_MAGIC`.
Right, that makes sense. Now, let me re-examine the panic message: `r3:57ac6e9d r2:8280001c r1:822a7804 r0:82298d68`. Hmm, `r3` is `57ac6e9d`. That *is* `STACK_END_MAGIC`, isn't it? Okay, so that suggests `r3` *should* be the magic value, but something else must have overwritten it. That means the comparison is failing, indicating corruption.
Alright, let's look at the assembly of `schedule_debug` or `__schedule`, see where we're checking this. Wait, the panic *is* actually in `schedule_debug`! Okay, let's trace this back to the `__schedule` function. Time to dig into `kernel/sched/core.c` and see what's going on there.
|
| 29/2 |
2026/05/15 18:16 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/sched/core.c IncludeLines:true Name:__schedule]
Results: map[SourceCode:6722: /*
6723: * __schedule() is the main scheduler function.
6724: *
6725: * The main means of driving the scheduler and thus entering this function are:
6726: *
6727: * 1. Explicit blocking: mutex, semaphore, waitqueue, etc.
6728: *
6729: * 2. TIF_NEED_RESCHED flag is checked on interrupt and userspace return
6730: * paths. For example, see arch/x86/entry_64.S.
6731: *
6732: * To drive preemption between tasks, the scheduler sets the flag in timer
6733: * interrupt handler sched_tick().
6734: *
6735: * 3. Wakeups don't really cause entry into schedule(). They add a
6736: * task to the run-queue and that's it.
6737: *
6738: * Now, if the new task added to the run-queue preempts the current
6739: * task, then the wakeup sets TIF_NEED_RESCHED and schedule() gets
6740: * called on the nearest possible occasion:
6741: *
6742: * - If the kernel is preemptible (CONFIG_PREEMPTION=y):
6743: *
6744: * - in syscall or exception context, at the next outmost
6745: * preempt_enable(). (this might be as soon as the wake_up()'s
6746: * spin_unlock()!)
6747: *
6748: * - in IRQ context, return from interrupt-handler to
6749: * preemptible context
6750: *
6751: * - If the kernel is not preemptible (CONFIG_PREEMPTION is not set)
6752: * then at the next:
6753: *
6754: * - cond_resched() call
6755: * - explicit schedule() call
6756: * - return from syscall or exception to user-space
6757: * - return from interrupt-handler to user-space
6758: *
6759: * WARNING: must be called with preemption disabled!
6760: */
6761: static void __sched notrace __schedule(int sched_mode)
6762: {
6763: struct task_struct *prev, *next;
6764: /*
6765: * On PREEMPT_RT kernel, SM_RTLOCK_WAIT is noted
6766: * as a preemption by schedule_debug() and RCU.
6767: */
6768: bool preempt = sched_mode > SM_NONE;
6769: bool is_switch = false;
6770: unsigned long *switch_count;
6771: unsigned long prev_state;
6772: struct rq_flags rf;
6773: struct rq *rq;
6774: int cpu;
6775:
6776: /* Trace preemptions consistently with task switches */
6777: trace_sched_entry_tp(sched_mode == SM_PREEMPT);
6778:
6779: cpu = smp_processor_id();
6780: rq = cpu_rq(cpu);
6781: prev = rq->curr;
6782:
6783: schedule_debug(prev, preempt);
6784:
6785: if (sched_feat(HRTICK) || sched_feat(HRTICK_DL))
6786: hrtick_clear(rq);
6787:
6788: klp_sched_try_switch(prev);
6789:
6790: local_irq_disable();
6791: rcu_note_context_switch(preempt);
6792: migrate_disable_switch(rq, prev);
6793:
6794: /*
6795: * Make sure that signal_pending_state()->signal_pending() below
6796: * can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
6797: * done by the caller to avoid the race with signal_wake_up():
6798: *
6799: * __set_current_state(@state) signal_wake_up()
6800: * schedule() set_tsk_thread_flag(p, TIF_SIGPENDING)
6801: * wake_up_state(p, state)
6802: * LOCK rq->lock LOCK p->pi_state
6803: * smp_mb__after_spinlock() smp_mb__after_spinlock()
6804: * if (signal_pending_state()) if (p->state & @state)
6805: *
6806: * Also, the membarrier system call requires a full memory barrier
6807: * after coming from user-space, before storing to rq->curr; this
6808: * barrier matches a full barrier in the proximity of the membarrier
6809: * system call exit.
6810: */
6811: rq_lock(rq, &rf);
6812: smp_mb__after_spinlock();
6813:
6814: /* Promote REQ to ACT */
6815: rq->clock_update_flags <<= 1;
6816: update_rq_clock(rq);
6817: rq->clock_update_flags = RQCF_UPDATED;
6818:
6819: switch_count = &prev->nivcsw;
6820:
6821: /* Task state changes only considers SM_PREEMPT as preemption */
6822: preempt = sched_mode == SM_PREEMPT;
6823:
6824: /*
6825: * We must load prev->state once (task_struct::state is volatile), such
6826: * that we form a control dependency vs deactivate_task() below.
6827: */
6828: prev_state = READ_ONCE(prev->__state);
6829: if (sched_mode == SM_IDLE) {
6830: /* SCX must consult the BPF scheduler to tell if rq is empty */
6831: if (!rq->nr_running && !scx_enabled()) {
6832: next = prev;
6833: goto picked;
6834: }
6835: } else if (!preempt && prev_state) {
6836: /*
6837: * We pass task_is_blocked() as the should_block arg
6838: * in order to keep mutex-blocked tasks on the runqueue
6839: * for slection with proxy-exec (without proxy-exec
6840: * task_is_blocked() will always be false).
6841: */
6842: try_to_block_task(rq, prev, &prev_state,
6843: !task_is_blocked(prev));
6844: switch_count = &prev->nvcsw;
6845: }
6846:
6847: pick_again:
6848: next = pick_next_task(rq, rq->donor, &rf);
6849: rq_set_donor(rq, next);
6850: rq->next_class = next->sched_class;
6851: if (unlikely(task_is_blocked(next))) {
6852: next = find_proxy_task(rq, next, &rf);
6853: if (!next)
6854: goto pick_again;
6855: if (next == rq->idle)
6856: goto keep_resched;
6857: }
6858: picked:
6859: clear_tsk_need_resched(prev);
6860: clear_preempt_need_resched();
6861: keep_resched:
6862: rq->last_seen_need_resched_ns = 0;
6863:
6864: is_switch = prev != next;
6865: if (likely(is_switch)) {
6866: rq->nr_switches++;
6867: /*
6868: * RCU users of rcu_dereference(rq->curr) may not see
6869: * changes to task_struct made by pick_next_task().
6870: */
6871: RCU_INIT_POINTER(rq->curr, next);
6872:
6873: if (!task_current_donor(rq, next))
6874: proxy_tag_curr(rq, next);
6875:
6876: /*
6877: * The membarrier system call requires each architecture
6878: * to have a full memory barrier after updating
6879: * rq->curr, before returning to user-space.
6880: *
6881: * Here are the schemes providing that barrier on the
6882: * various architectures:
6883: * - mm ? switch_mm() : mmdrop() for x86, s390, sparc, PowerPC,
6884: * RISC-V. switch_mm() relies on membarrier_arch_switch_mm()
6885: * on PowerPC and on RISC-V.
6886: * - finish_lock_switch() for weakly-ordered
6887: * architectures where spin_unlock is a full barrier,
6888: * - switch_to() for arm64 (weakly-ordered, spin_unlock
6889: * is a RELEASE barrier),
6890: *
6891: * The barrier matches a full barrier in the proximity of
6892: * the membarrier system call entry.
6893: *
6894: * On RISC-V, this barrier pairing is also needed for the
6895: * SYNC_CORE command when switching between processes, cf.
6896: * the inline comments in membarrier_arch_switch_mm().
6897: */
6898: ++*switch_count;
6899:
6900: psi_account_irqtime(rq, prev, next);
6901: psi_sched_switch(prev, next, !task_on_rq_queued(prev) ||
6902: prev->se.sched_delayed);
6903:
6904: trace_sched_switch(preempt, prev, next, prev_state);
6905:
6906: /* Also unlocks the rq: */
6907: rq = context_switch(rq, prev, next, &rf);
6908: } else {
6909: /* In case next was already curr but just got blocked_donor */
6910: if (!task_current_donor(rq, next))
6911: proxy_tag_curr(rq, next);
6912:
6913: rq_unpin_lock(rq, &rf);
6914: __balance_callbacks(rq, NULL);
6915: raw_spin_rq_unlock_irq(rq);
6916: }
6917: trace_sched_exit_tp(is_switch);
6918: }
SourceFile:kernel/sched/core.c]
|
| 30/2 |
2026/05/15 18:16 |
llm |
expert |
0m
Model:
Tokens:
input: 24051
output: 17
thoughts: 478
Thoughts: **Analyzing a Kernel Panic in `__schedule`**
Okay, so I'm looking at this kernel panic from the `__schedule` function. It looks like the system is panicking within `__schedule` itself, and the traceback is pointing me towards a stack corruption check. Specifically, the panic is occurring within `task_stack_end_corrupted`. Let's break this down.
It looks like the code is trying to read the end of the stack, specifically `*(task->stack)`, and compare it against `STACK_END_MAGIC`. If they're not equal, it panics. The `task` in question here is `swapper/0`, which is the initial task, and right now, `task->stack` is pointing to the `init_stack`.
Now, the panic trace gives me a few register values: `r3:57ac6e9d`, `r2:8280001c`, `r1:822a7804`, and `r0:82298d68`. The crucial one here is `r3`, which is the value that was compared against the value from the stack. Looking at the value, `r3` *is* `STACK_END_MAGIC`. So, the compiler loaded `STACK_END_MAGIC` into `r3` to prepare for the comparison. That means the value *read* from `*(task->stack)` must be something different, and that's the problem.
Why would the `swapper/0`'s stack be corrupted? The stack of `swapper/0` is the initial stack, which should be pretty sacrosanct. This is where I need to check the definition of `init_stack`. I need to figure out how it's initialized and if there's any way it could be overwritten early in the boot process. Let's see...
|
| 31/2 |
2026/05/15 18:16 |
tool |
grepper |
0m
Args: map[Expression:init_stack]
Results: map[Output:
Full output is too long, showing 500 out of 624 lines.
Use more precise expression if possible.
[arch/arm/include/asm/stackprotector.h=20=extern unsigned long __stack_chk_guard;
--
arch/arm/include/asm/stackprotector.h-27- */
arch/arm/include/asm/stackprotector.h:28:static __always_inline void boot_init_stack_canary(void)
arch/arm/include/asm/stackprotector.h-29-{
--
arch/arm64/include/asm/stackprotector.h=18=extern unsigned long __stack_chk_guard;
--
arch/arm64/include/asm/stackprotector.h-25- */
arch/arm64/include/asm/stackprotector.h:26:static __always_inline void boot_init_stack_canary(void)
arch/arm64/include/asm/stackprotector.h-27-{
--
arch/arm64/kernel/head.S=85=SYM_CODE_START(primary_entry)
--
arch/arm64/kernel/head.S-88-
arch/arm64/kernel/head.S:89: adrp x1, early_init_stack
arch/arm64/kernel/head.S-90- mov sp, x1
--
arch/arm64/kernel/head.S=508=SYM_FUNC_START_LOCAL(__primary_switch)
--
arch/arm64/kernel/head.S-512-
arch/arm64/kernel/head.S:513: adrp x1, early_init_stack
arch/arm64/kernel/head.S-514- mov sp, x1
--
arch/arm64/kernel/vmlinux.lds.S=163=SECTIONS
--
arch/arm64/kernel/vmlinux.lds.S-342- . += SZ_4K; /* stack for the early C runtime */
arch/arm64/kernel/vmlinux.lds.S:343: early_init_stack = .;
arch/arm64/kernel/vmlinux.lds.S-344-
--
arch/csky/include/asm/processor.h=41=struct thread_struct {
--
arch/csky/include/asm/processor.h-49-#define INIT_THREAD { \
arch/csky/include/asm/processor.h:50: .sp = sizeof(init_stack) + (unsigned long) &init_stack, \
arch/csky/include/asm/processor.h-51-}
--
arch/csky/include/asm/stackprotector.h=5=extern unsigned long __stack_chk_guard;
--
arch/csky/include/asm/stackprotector.h-12- */
arch/csky/include/asm/stackprotector.h:13:static __always_inline void boot_init_stack_canary(void)
arch/csky/include/asm/stackprotector.h-14-{
--
arch/loongarch/include/asm/stackprotector.h=18=extern unsigned long __stack_chk_guard;
--
arch/loongarch/include/asm/stackprotector.h-25- */
arch/loongarch/include/asm/stackprotector.h:26:static __always_inline void boot_init_stack_canary(void)
arch/loongarch/include/asm/stackprotector.h-27-{
--
arch/m68k/include/asm/processor.h=118=struct thread_struct {
--
arch/m68k/include/asm/processor.h-132-#define INIT_THREAD { \
arch/m68k/include/asm/processor.h:133: .ksp = sizeof(init_stack) + (unsigned long) init_stack, \
arch/m68k/include/asm/processor.h-134- .sr = PS_S, \
--
arch/microblaze/include/asm/processor.h=53=struct thread_struct {
--
arch/microblaze/include/asm/processor.h-61-# define INIT_THREAD { \
arch/microblaze/include/asm/processor.h:62: .ksp = sizeof init_stack + (unsigned long)init_stack, \
arch/microblaze/include/asm/processor.h-63- .pgdir = swapper_pg_dir, \
--
arch/mips/include/asm/stackprotector.h=18=extern unsigned long __stack_chk_guard;
--
arch/mips/include/asm/stackprotector.h-25- */
arch/mips/include/asm/stackprotector.h:26:static __always_inline void boot_init_stack_canary(void)
arch/mips/include/asm/stackprotector.h-27-{
--
arch/openrisc/include/asm/processor.h=46=struct thread_struct {
--
arch/openrisc/include/asm/processor.h-65-
arch/openrisc/include/asm/processor.h:66:#define INIT_SP (sizeof(init_stack) + (unsigned long) &init_stack)
arch/openrisc/include/asm/processor.h-67-
--
arch/parisc/kernel/head.S=33=END(boot_args)
--
arch/parisc/kernel/head.S-38- .import init_task,data
arch/parisc/kernel/head.S:39: .import init_stack,data
arch/parisc/kernel/head.S-40- .import fault_vector_20,code /* IVA parisc 2.0 32 bit */
--
arch/parisc/kernel/head.S=84=$iodc_panic:
--
arch/parisc/kernel/head.S-86- copy %arg1, %r11
arch/parisc/kernel/head.S:87: load32 PA(init_stack),%sp
arch/parisc/kernel/head.S-88-#define MEM_CONS 0x3A0
--
arch/parisc/kernel/head.S=154=$pgt_fill_loop:
--
arch/parisc/kernel/head.S-170- /* And the stack pointer too */
arch/parisc/kernel/head.S:171: load32 init_stack,%sp
arch/parisc/kernel/head.S-172- tophys_r1 %sp
--
arch/powerpc/include/asm/processor.h=133=struct thread_struct {
--
arch/powerpc/include/asm/processor.h-269-
arch/powerpc/include/asm/processor.h:270:#define INIT_SP (sizeof(init_stack) + (unsigned long) &init_stack)
arch/powerpc/include/asm/processor.h:271:#define INIT_SP_LIMIT ((unsigned long)&init_stack)
arch/powerpc/include/asm/processor.h-272-
--
arch/powerpc/include/asm/stackprotector.h-19- */
arch/powerpc/include/asm/stackprotector.h:20:static __always_inline void boot_init_stack_canary(void)
arch/powerpc/include/asm/stackprotector.h-21-{
--
arch/powerpc/kernel/setup_32.c=146=void __init irqstack_early_init(void)
--
arch/powerpc/kernel/setup_32.c-161-#ifdef CONFIG_VMAP_STACK
arch/powerpc/kernel/setup_32.c:162:void *emergency_ctx[NR_CPUS] __ro_after_init = {[0] = &init_stack};
arch/powerpc/kernel/setup_32.c-163-
--
arch/powerpc/kernel/smp.c=1640=void start_secondary(void *unused)
--
arch/powerpc/kernel/smp.c-1698-
arch/powerpc/kernel/smp.c:1699: boot_init_stack_canary();
arch/powerpc/kernel/smp.c-1700-
--
arch/riscv/include/asm/processor.h=129=static inline void arch_thread_struct_whitelist(unsigned long *offset,
--
arch/riscv/include/asm/processor.h-136-#define INIT_THREAD { \
arch/riscv/include/asm/processor.h:137: .sp = sizeof(init_stack) + (long)&init_stack, \
arch/riscv/include/asm/processor.h-138- .align_ctl = PR_UNALIGN_NOPRINT, \
--
arch/riscv/include/asm/scs.h-10-/* Load init_shadow_call_stack to gp. */
arch/riscv/include/asm/scs.h:11:.macro scs_load_init_stack
arch/riscv/include/asm/scs.h-12- la gp, init_shadow_call_stack
--
arch/riscv/include/asm/scs.h-39-
arch/riscv/include/asm/scs.h:40:.macro scs_load_init_stack
arch/riscv/include/asm/scs.h-41-.endm
--
arch/riscv/include/asm/stackprotector.h=6=extern unsigned long __stack_chk_guard;
--
arch/riscv/include/asm/stackprotector.h-13- */
arch/riscv/include/asm/stackprotector.h:14:static __always_inline void boot_init_stack_canary(void)
arch/riscv/include/asm/stackprotector.h-15-{
--
arch/riscv/kernel/head.S=217=SYM_CODE_START(_start_kernel)
--
arch/riscv/kernel/head.S-324- addi sp, sp, -PT_SIZE_ON_STACK
arch/riscv/kernel/head.S:325: scs_load_init_stack
arch/riscv/kernel/head.S-326-#ifdef CONFIG_BUILTIN_DTB
--
arch/s390/include/asm/processor.h=212=typedef struct thread_struct thread_struct;
--
arch/s390/include/asm/processor.h-216-#define INIT_THREAD { \
arch/s390/include/asm/processor.h:217: .ksp = sizeof(init_stack) + (unsigned long) &init_stack, \
arch/s390/include/asm/processor.h-218- .last_break = 1, \
--
arch/s390/include/asm/stackprotector.h-9-
arch/s390/include/asm/stackprotector.h:10:static __always_inline void boot_init_stack_canary(void)
arch/s390/include/asm/stackprotector.h-11-{
--
arch/sh/boot/compressed/head_32.S=70=l1:
--
arch/sh/boot/compressed/head_32.S-75- /* Set the initial pointer. */
arch/sh/boot/compressed/head_32.S:76: mov.l init_stack_addr, r0
arch/sh/boot/compressed/head_32.S-77- mov.l @r0, r15
--
arch/sh/boot/compressed/head_32.S=96=kexec_magic:
arch/sh/boot/compressed/head_32.S-97- .long 0x400000F0 /* magic used by kexec to parse zImage format */
arch/sh/boot/compressed/head_32.S:98:init_stack_addr:
arch/sh/boot/compressed/head_32.S-99- .long stack_start
--
arch/sh/include/asm/processor_32.h=91=struct thread_struct {
--
arch/sh/include/asm/processor_32.h-121-#define INIT_THREAD { \
arch/sh/include/asm/processor_32.h:122: .sp = sizeof(init_stack) + (long) &init_stack, \
arch/sh/include/asm/processor_32.h-123- .flags = 0, \
--
arch/sh/include/asm/stackprotector.h=5=extern unsigned long __stack_chk_guard;
--
arch/sh/include/asm/stackprotector.h-12- */
arch/sh/include/asm/stackprotector.h:13:static __always_inline void boot_init_stack_canary(void)
arch/sh/include/asm/stackprotector.h-14-{
--
arch/sh/lib/mcount.S-38- * addresses for kernel stacks are anywhere after the bss
arch/sh/lib/mcount.S:39: * (after __bss_stop) and anywhere in init_thread_union (init_stack).
arch/sh/lib/mcount.S-40- */
--
arch/sh/lib/mcount.S-64- \
arch/sh/lib/mcount.S:65: /* If sp < init_stack, we're not OK. */ \
arch/sh/lib/mcount.S-66- mov.l .L_init_thread_union, r1; \
--
arch/sh/lib/mcount.S-69- \
arch/sh/lib/mcount.S:70: /* If sp > init_stack && sp < __bss_stop, not OK. */ \
arch/sh/lib/mcount.S-71- add r0, r1; \
--
arch/sparc/include/asm/processor_32.h=36=struct thread_struct {
--
arch/sparc/include/asm/processor_32.h-51-#define INIT_THREAD { \
arch/sparc/include/asm/processor_32.h:52: .kregs = (struct pt_regs *)(init_stack+THREAD_SIZE)-1 \
arch/sparc/include/asm/processor_32.h-53-}
--
arch/sparc/include/asm/thread_info_64.h=36=struct thread_info {
--
arch/sparc/include/asm/thread_info_64.h-118- .preempt_count = INIT_PREEMPT_COUNT, \
arch/sparc/include/asm/thread_info_64.h:119: .kregs = (struct pt_regs *)(init_stack+THREAD_SIZE)-1 \
arch/sparc/include/asm/thread_info_64.h-120-}
--
arch/um/os-Linux/skas/mem.c=25=void syscall_stub_dump_error(struct mm_id *mm_idp)
--
arch/um/os-Linux/skas/mem.c-57-
arch/um/os-Linux/skas/mem.c:58:static inline unsigned long *check_init_stack(struct mm_id * mm_idp,
arch/um/os-Linux/skas/mem.c-59- unsigned long *stack)
--
arch/x86/include/asm/processor.h=636=static __always_inline void prefetchw(const void *x)
--
arch/x86/include/asm/processor.h-642-
arch/x86/include/asm/processor.h:643:#define TOP_OF_INIT_STACK ((unsigned long)&init_stack + sizeof(init_stack) - \
arch/x86/include/asm/processor.h-644- TOP_OF_KERNEL_STACK_PADDING)
--
arch/x86/include/asm/stackprotector.h=23=DECLARE_PER_CPU_CACHE_HOT(unsigned long, __stack_chk_guard);
--
arch/x86/include/asm/stackprotector.h-35- */
arch/x86/include/asm/stackprotector.h:36:static __always_inline void boot_init_stack_canary(void)
arch/x86/include/asm/stackprotector.h-37-{
--
arch/x86/include/asm/stackprotector.h-43-
arch/x86/include/asm/stackprotector.h:44:static inline void cpu_init_stack_canary(int cpu, struct task_struct *idle)
arch/x86/include/asm/stackprotector.h-45-{
--
arch/x86/include/asm/stackprotector.h-50-
arch/x86/include/asm/stackprotector.h:51:/* dummy boot_init_stack_canary() is defined in linux/stackprotector.h */
arch/x86/include/asm/stackprotector.h-52-
arch/x86/include/asm/stackprotector.h:53:static inline void cpu_init_stack_canary(int cpu, struct task_struct *idle)
arch/x86/include/asm/stackprotector.h-54-{ }
--
arch/x86/kernel/smpboot.c=881=int common_cpu_up(unsigned int cpu, struct task_struct *idle)
--
arch/x86/kernel/smpboot.c-888- per_cpu(current_task, cpu) = idle;
arch/x86/kernel/smpboot.c:889: cpu_init_stack_canary(cpu, idle);
arch/x86/kernel/smpboot.c-890-
--
arch/x86/kernel/vmlinux.lds.S=124=SECTIONS
--
arch/x86/kernel/vmlinux.lds.S-182- /* equivalent to task_pt_regs(&init_task) */
arch/x86/kernel/vmlinux.lds.S:183: __top_init_kernel_stack = __end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE;
arch/x86/kernel/vmlinux.lds.S-184-
--
arch/xtensa/include/asm/processor.h=153=struct thread_struct {
--
arch/xtensa/include/asm/processor.h-172- ra: 0, \
arch/xtensa/include/asm/processor.h:173: sp: sizeof(init_stack) + (long) &init_stack, \
arch/xtensa/include/asm/processor.h-174-}
--
arch/xtensa/include/asm/stackprotector.h=17=extern unsigned long __stack_chk_guard;
--
arch/xtensa/include/asm/stackprotector.h-24- */
arch/xtensa/include/asm/stackprotector.h:25:static __always_inline void boot_init_stack_canary(void)
arch/xtensa/include/asm/stackprotector.h-26-{
--
drivers/acpi/acpica/acutils.h=289=acpi_ut_update_object_reference(union acpi_operand_object *object, u16 action);
--
drivers/acpi/acpica/acutils.h-293- */
drivers/acpi/acpica/acutils.h:294:void acpi_ut_init_stack_ptr_trace(void);
drivers/acpi/acpica/acutils.h-295-
--
drivers/acpi/acpica/utdebug.c=22=static const char *acpi_gbl_function_exit_prefix = "----Exit-";
--
drivers/acpi/acpica/utdebug.c-25- *
drivers/acpi/acpica/utdebug.c:26: * FUNCTION: acpi_ut_init_stack_ptr_trace
drivers/acpi/acpica/utdebug.c-27- *
--
drivers/acpi/acpica/utdebug.c-35-
drivers/acpi/acpica/utdebug.c:36:void acpi_ut_init_stack_ptr_trace(void)
drivers/acpi/acpica/utdebug.c-37-{
--
drivers/acpi/acpica/utxfinit.c=38=acpi_status ACPI_INIT_FUNCTION acpi_initialize_subsystem(void)
--
drivers/acpi/acpica/utxfinit.c-44- acpi_gbl_startup_flags = ACPI_SUBSYSTEM_INITIALIZE;
drivers/acpi/acpica/utxfinit.c:45: ACPI_DEBUG_EXEC(acpi_ut_init_stack_ptr_trace());
drivers/acpi/acpica/utxfinit.c-46-
--
drivers/md/bcache/btree.c=243=static void bch_btree_node_read(struct btree *b)
--
drivers/md/bcache/btree.c-250-
drivers/md/bcache/btree.c:251: closure_init_stack(&cl);
drivers/md/bcache/btree.c-252-
--
drivers/md/bcache/btree.c=452=static void bch_btree_node_write_sync(struct btree *b)
--
drivers/md/bcache/btree.c-455-
drivers/md/bcache/btree.c:456: closure_init_stack(&cl);
drivers/md/bcache/btree.c-457-
--
drivers/md/bcache/btree.c=606=static int mca_reap(struct btree *b, unsigned int min_order, bool flush)
--
drivers/md/bcache/btree.c-609-
drivers/md/bcache/btree.c:610: closure_init_stack(&cl);
drivers/md/bcache/btree.c-611- lockdep_assert_held(&b->c->bucket_lock);
--
drivers/md/bcache/btree.c=746=void bch_btree_cache_free(struct cache_set *c)
--
drivers/md/bcache/btree.c-750-
drivers/md/bcache/btree.c:751: closure_init_stack(&cl);
drivers/md/bcache/btree.c-752-
--
drivers/md/bcache/btree.c=1359=static int btree_gc_coalesce(struct btree *b, struct btree_op *op,
--
drivers/md/bcache/btree.c-1373- memset(new_nodes, 0, sizeof(new_nodes));
drivers/md/bcache/btree.c:1374: closure_init_stack(&cl);
drivers/md/bcache/btree.c-1375-
--
drivers/md/bcache/btree.c=1826=static void bch_btree_gc(struct cache_set *c)
--
drivers/md/bcache/btree.c-1836- memset(&stats, 0, sizeof(struct gc_stat));
drivers/md/bcache/btree.c:1837: closure_init_stack(&writes);
drivers/md/bcache/btree.c-1838- bch_btree_op_init(&op, SHRT_MAX);
--
drivers/md/bcache/btree.c=2237=static int btree_split(struct btree *b, struct btree_op *op,
--
drivers/md/bcache/btree.c-2246-
drivers/md/bcache/btree.c:2247: closure_init_stack(&cl);
drivers/md/bcache/btree.c-2248- bch_keylist_init(&parent_keys);
--
drivers/md/bcache/btree.c=2371=static int bch_btree_insert_node(struct btree *b, struct btree_op *op,
--
drivers/md/bcache/btree.c-2379-
drivers/md/bcache/btree.c:2380: closure_init_stack(&cl);
drivers/md/bcache/btree.c-2381-
--
drivers/md/bcache/btree.c=2519=void bch_btree_set_root(struct btree *b)
--
drivers/md/bcache/btree.c-2523-
drivers/md/bcache/btree.c:2524: closure_init_stack(&cl);
drivers/md/bcache/btree.c-2525-
--
drivers/md/bcache/journal.c=35=static int journal_read_bucket(struct cache *ca, struct list_head *list,
--
drivers/md/bcache/journal.c-47-
drivers/md/bcache/journal.c:48: closure_init_stack(&cl);
drivers/md/bcache/journal.c-49-
--
drivers/md/bcache/journal.c=773=static struct journal_write *journal_wait_for_write(struct cache_set *c,
--
drivers/md/bcache/journal.c-781-
drivers/md/bcache/journal.c:782: closure_init_stack(&cl);
drivers/md/bcache/journal.c-783-
--
drivers/md/bcache/movinggc.c=126=static void read_moving(struct cache_set *c)
--
drivers/md/bcache/movinggc.c-132-
drivers/md/bcache/movinggc.c:133: closure_init_stack(&cl);
drivers/md/bcache/movinggc.c-134-
--
drivers/md/bcache/super.c=498=static int __uuid_write(struct cache_set *c)
--
drivers/md/bcache/super.c-504-
drivers/md/bcache/super.c:505: closure_init_stack(&cl);
drivers/md/bcache/super.c-506- lockdep_assert_held(&bch_register_lock);
--
drivers/md/bcache/super.c=590=static void prio_io(struct cache *ca, uint64_t bucket, blk_opf_t opf)
--
drivers/md/bcache/super.c-594-
drivers/md/bcache/super.c:595: closure_init_stack(cl);
drivers/md/bcache/super.c-596-
--
drivers/md/bcache/super.c=610=int bch_prio_write(struct cache *ca, bool wait)
--
drivers/md/bcache/super.c-632-
drivers/md/bcache/super.c:633: closure_init_stack(&cl);
drivers/md/bcache/super.c-634-
--
drivers/md/bcache/super.c=1050=int bch_cached_dev_run(struct cached_dev *dc)
--
drivers/md/bcache/super.c-1077-
drivers/md/bcache/super.c:1078: closure_init_stack(&cl);
drivers/md/bcache/super.c-1079-
--
drivers/md/bcache/super.c=1196=int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c,
--
drivers/md/bcache/super.c-1265-
drivers/md/bcache/super.c:1266: closure_init_stack(&cl);
drivers/md/bcache/super.c-1267-
--
drivers/md/bcache/super.c=1978=static int run_cache_set(struct cache_set *c)
--
drivers/md/bcache/super.c-1986-
drivers/md/bcache/super.c:1987: closure_init_stack(&cl);
drivers/md/bcache/super.c-1988-
--
drivers/md/bcache/writeback.c=474=static void read_dirty(struct cached_dev *dc)
--
drivers/md/bcache/writeback.c-485- atomic_set(&dc->writeback_sequence_next, sequence);
drivers/md/bcache/writeback.c:486: closure_init_stack(&cl);
drivers/md/bcache/writeback.c-487-
--
drivers/md/bcache/writeback.c=739=static int bch_writeback_thread(void *arg)
--
drivers/md/bcache/writeback.c-788-
drivers/md/bcache/writeback.c:789: closure_init_stack(&cl);
drivers/md/bcache/writeback.c-790- memset(&dc->sb.set_uuid, 0, 16);
--
drivers/md/md-linear.c=68=static int linear_set_limits(struct mddev *mddev)
--
drivers/md/md-linear.c-72-
drivers/md/md-linear.c:73: md_init_stacking_limits(&lim);
drivers/md/md-linear.c-74- lim.max_hw_sectors = mddev->chunk_sectors;
--
drivers/md/md.c=6262=static void mddev_delayed_delete(struct work_struct *ws)
--
drivers/md/md.c-6268-
drivers/md/md.c:6269:void md_init_stacking_limits(struct queue_limits *lim)
drivers/md/md.c-6270-{
--
drivers/md/md.c-6274-}
drivers/md/md.c:6275:EXPORT_SYMBOL_GPL(md_init_stacking_limits);
drivers/md/md.c-6276-
--
drivers/md/md.h=939=extern void mddev_destroy(struct mddev *mddev);
drivers/md/md.h:940:void md_init_stacking_limits(struct queue_limits *lim);
drivers/md/md.h-941-struct mddev *md_alloc(dev_t dev, char *name);
--
drivers/md/raid0.c=381=static int raid0_set_limits(struct mddev *mddev)
--
drivers/md/raid0.c-385-
drivers/md/raid0.c:386: md_init_stacking_limits(&lim);
drivers/md/raid0.c-387- lim.max_hw_sectors = mddev->chunk_sectors;
--
drivers/md/raid1.c=3185=static int raid1_set_limits(struct mddev *mddev)
--
drivers/md/raid1.c-3189-
drivers/md/raid1.c:3190: md_init_stacking_limits(&lim);
drivers/md/raid1.c-3191- lim.max_write_zeroes_sectors = 0;
--
drivers/md/raid10.c=3928=static int raid10_set_queue_limits(struct mddev *mddev)
--
drivers/md/raid10.c-3933-
drivers/md/raid10.c:3934: md_init_stacking_limits(&lim);
drivers/md/raid10.c-3935- lim.max_write_zeroes_sectors = 0;
--
drivers/md/raid5.c=7760=static int raid5_set_limits(struct mddev *mddev)
--
drivers/md/raid5.c-7778-
drivers/md/raid5.c:7779: md_init_stacking_limits(&lim);
drivers/md/raid5.c-7780- lim.logical_block_size = mddev->logical_block_size;
--
fs/exec.c=256=static int bprm_mm_init(struct linux_binprm *bprm)
--
fs/exec.c-273-#else
fs/exec.c:274: err = create_init_stack_vma(bprm->mm, &bprm->vma, &bprm->p);
fs/exec.c-275- if (err)
--
include/asm-generic/vmlinux.lds.h-426- . = ALIGN(align); \
include/asm-generic/vmlinux.lds.h:427: __start_init_stack = .; \
include/asm-generic/vmlinux.lds.h-428- init_thread_union = .; \
include/asm-generic/vmlinux.lds.h:429: init_stack = .; \
include/asm-generic/vmlinux.lds.h-430- KEEP(*(.data..init_thread_info)) \
include/asm-generic/vmlinux.lds.h:431: . = __start_init_stack + THREAD_SIZE; \
include/asm-generic/vmlinux.lds.h:432: __end_init_stack = .;
include/asm-generic/vmlinux.lds.h-433-
--
include/linux/bpf.h=2730=static inline bool bpf_allow_ptr_leaks(const struct bpf_token *token)
--
include/linux/bpf.h-2734-
include/linux/bpf.h:2735:static inline bool bpf_allow_uninit_stack(const struct bpf_token *token)
include/linux/bpf.h-2736-{
--
include/linux/bpf_verifier.h=748=struct bpf_verifier_env {
--
include/linux/bpf_verifier.h-779- */
include/linux/bpf_verifier.h:780: bool allow_uninit_stack;
include/linux/bpf_verifier.h-781- bool bpf_capable;
--
include/linux/closure.h=309=static inline void closure_init(struct closure *cl, struct closure *parent)
--
include/linux/closure.h-322-
include/linux/closure.h:323:static inline void closure_init_stack(struct closure *cl)
include/linux/closure.h-324-{
--
include/linux/closure.h-331-
include/linux/closure.h:332:static inline void closure_init_stack_release(struct closure *cl)
include/linux/closure.h-333-{
--
include/linux/closure.h=436=do { \
--
include/linux/closure.h-438- \
include/linux/closure.h:439: closure_init_stack(&cl); \
include/linux/closure.h-440- \
--
include/linux/closure.h=452=do { \
--
include/linux/closure.h-461- \
include/linux/closure.h:462: closure_init_stack(&cl); \
include/linux/closure.h-463- \
--
include/linux/sched.h=1958=extern struct thread_info init_thread_info;
--
include/linux/sched.h-1960-
include/linux/sched.h:1961:extern unsigned long init_stack[THREAD_SIZE / sizeof(unsigned long)];
include/linux/sched.h-1962-
--
include/linux/stackprotector.h=23=static inline unsigned long get_random_canary(void)
--
include/linux/stackprotector.h-30-#else
include/linux/stackprotector.h:31:static inline void boot_init_stack_canary(void)
include/linux/stackprotector.h-32-{
--
init/init_task.c=96=struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
--
init/init_task.c-101- .__state = 0,
init/init_task.c:102: .stack = init_stack,
init/init_task.c-103- .usage = REFCOUNT_INIT(2),
]
]
|
| 32/2 |
2026/05/15 18:16 |
llm |
expert |
0m
Model:
Tokens:
input: 34281
output: 23
thoughts: 205
Thoughts: **My Initial Thoughts on the Initialization Stack**
Okay, so I'm looking at `init_stack` and it's defined in `include/asm-generic/vmlinux.lds.h`. Let me quickly check the code snippet... right, `init_stack` is being defined as part of the linker script magic for the initial thread. It looks like we're setting up the initial thread stack, aligning it, and defining start and end markers. I see `init_thread_union = .` and `init_stack = .` which I assume implies an array of some type.
Ah, yes, `init_stack` is an array of `unsigned long`. That clicks. And it's assigned to `init_task.stack`. So `end_of_stack(&init_task)` *should* translate directly to `init_stack`. That's straightforward enough.
Now, a red flag! I seem to recall something about `set_task_stack_end_magic(&init_task)` being called during the boot process, and that's concerning. That's used to put a marker at the end of the stack, which is critical for stack overflow detection, and that's an area I'm always meticulous about. Let's make sure that's happening as expected. I need to track down where `set_task_stack_end_magic` is actually being called during the boot sequence to ensure everything's properly initialized. I'll need to double check the kernel's initialization path for that.
|
| 33/2 |
2026/05/15 18:16 |
tool |
grepper |
0m
Args: map[Expression:set_task_stack_end_magic]
Results: map[Output:include/linux/sched/task_stack.h=102=static inline unsigned long stack_not_used(struct task_struct *p)
--
include/linux/sched/task_stack.h-106-#endif
include/linux/sched/task_stack.h:107:extern void set_task_stack_end_magic(struct task_struct *tsk);
include/linux/sched/task_stack.h-108-
--
init/main.c=1008=void start_kernel(void)
--
init/main.c-1012-
init/main.c:1013: set_task_stack_end_magic(&init_task);
init/main.c-1014- smp_setup_processor_id();
--
kernel/fork.c=894=int __weak arch_dup_task_struct(struct task_struct *dst,
--
kernel/fork.c-900-
kernel/fork.c:901:void set_task_stack_end_magic(struct task_struct *tsk)
kernel/fork.c-902-{
--
kernel/fork.c=909=static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
--
kernel/fork.c-949- clear_tsk_need_resched(tsk);
kernel/fork.c:950: set_task_stack_end_magic(tsk);
kernel/fork.c-951- clear_syscall_work_syscall_user_dispatch(tsk);
]
|
| 34/2 |
2026/05/15 18:17 |
llm |
expert |
0m
Model:
Tokens:
input: 35234
output: 24
thoughts: 1106
Thoughts: **Analyzing a Kernel Stack Corruption Panic**
Okay, so I'm looking at this kernel panic, and it's all about a corrupted stack end being detected inside the scheduler. The trace starts with `set_task_stack_end_magic` being called in `start_kernel`. That should set the magic value, `STACK_END_MAGIC`, at the end of the `init_task` stack, which I'm assuming is the initial stack for the idle thread, `swapper/0`. The problem is, later, `schedule_debug` panics because `task_stack_end_corrupted(prev)` returns true. Why? What could overwrite that magic value?
The panic message gives me register values: `r3` is `STACK_END_MAGIC`, which is good. But then I have to look at `r2`, `r1`, and `r0`. `r2` is `8280001c`, `r1` is `822a7804`, and `r0` is `82298d68`. Hmm, `8280001c` looks like a kernel address. I wonder if it's the `init_stack`. If `init_stack` is `82800000`, then `8280001c` would be `init_stack + 0x1c`.
I need to figure out what's placed in `init_stack`. In ARM, `init_thread_union` gets placed in `.data..init_thread_info` or `.data..init_task`. Now, if the stack is overwritten, what could do that? Is this a known syzkaller or kernel bug?
The report indicates a `SOFTLOCKUP`. That's a red flag. A softlockup means a CPU was stuck somewhere, and the watchdog fired. But the call trace doesn't show the watchdog itself, just the backtrace leading to the panic in `schedule_debug`. Maybe the softlockup happened *before* the panic, and the kernel continued on to panic later? Or maybe the watchdog interrupted something that caused the panic?
`schedule_debug` is called from `__schedule`, which means we're in the scheduler. If the stack *is* corrupted, it could be a stack overflow, most likely from the idle thread. `swapper/0` is the idle thread, just running `do_idle`. Why would the idle thread's stack overflow? If it *did* overflow, it would overwrite the `init_stack[0]`.
Wait, let's look at `r2:8280001c` again. If `r2` is the address of `end_of_stack`, and `end_of_stack` is a member of the task structure, then where does `task->stack` start? So, `end_of_stack` is at `8280001c`, and that's the end of the idle task stack? Wait, isn't ARM supposed to use `CONFIG_THREAD_INFO_IN_TASK`? Let me double-check the Kconfig...
|
| 35/2 |
2026/05/15 18:17 |
tool |
grepper |
0m
Args: map[Expression:CONFIG_THREAD_INFO_IN_TASK=]
Results: map[Output:Documentation/process/deprecated.rst=196=lead to a crash, possible overwriting sensitive contents at the end of the
Documentation/process/deprecated.rst:197:stack (when built without `CONFIG_THREAD_INFO_IN_TASK=y`), or overwriting
Documentation/process/deprecated.rst-198-memory adjacent to the stack (when built without `CONFIG_VMAP_STACK=y`)
--
Documentation/translations/it_IT/process/deprecated.rst=215=dati importanti alla fine dello stack (quando il kernel è compilato senza
Documentation/translations/it_IT/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente
Documentation/translations/it_IT/process/deprecated.rst-217-allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`).
--
Documentation/translations/sp_SP/process/deprecated.rst=215=de contenido al final de la pila (cuando se construye sin
Documentation/translations/sp_SP/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente
Documentation/translations/sp_SP/process/deprecated.rst-217-a la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`).
--
arch/arm/kernel/entry-armv.S=512=ENTRY(__switch_to)
--
arch/arm/kernel/entry-armv.S-573-
arch/arm/kernel/entry-armv.S:574: @ When CONFIG_THREAD_INFO_IN_TASK=n, the update of SP itself is what
arch/arm/kernel/entry-armv.S-575- @ effectuates the task switch, as that is what causes the observable
arch/arm/kernel/entry-armv.S-576- @ values of current and current_thread_info to change. When
arch/arm/kernel/entry-armv.S:577: @ CONFIG_THREAD_INFO_IN_TASK=y, setting current (and therefore
arch/arm/kernel/entry-armv.S-578- @ current_thread_info) is done explicitly, and the update of SP just
]
|
| 36/2 |
2026/05/15 18:17 |
llm |
expert |
0m
Model:
Tokens:
input: 37616
output: 23
thoughts: 11
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Investigating Configuration Possibilities**
Okay, so I'm thinking, before I dive too deep into this, I should probably check the configuration files. It's almost reflexive at this point – I need to see what's already set up and if there's any existing configuration that could impact this process. Specifically, I should look in the `.config` directory. That's usually the first place to look for user-specific customizations or application-level settings. A quick inspection there could save a lot of debugging time later. Knowing what's configured, and more importantly, *how* it's configured, will be key to avoiding redundant work or introducing conflicts. Let's see what's in there.
|
| 37/2 |
2026/05/15 18:17 |
tool |
grepper |
0m
Args: map[Expression:CONFIG_THREAD_INFO_IN_TASK]
Results: map[Output:Documentation/process/deprecated.rst=196=lead to a crash, possible overwriting sensitive contents at the end of the
Documentation/process/deprecated.rst:197:stack (when built without `CONFIG_THREAD_INFO_IN_TASK=y`), or overwriting
Documentation/process/deprecated.rst-198-memory adjacent to the stack (when built without `CONFIG_VMAP_STACK=y`)
--
Documentation/translations/it_IT/process/deprecated.rst=215=dati importanti alla fine dello stack (quando il kernel è compilato senza
Documentation/translations/it_IT/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sovrascrivere un pezzo di memoria adiacente
Documentation/translations/it_IT/process/deprecated.rst-217-allo stack (quando il kernel è compilato senza `CONFIG_VMAP_STACK=y`).
--
Documentation/translations/sp_SP/process/deprecated.rst=215=de contenido al final de la pila (cuando se construye sin
Documentation/translations/sp_SP/process/deprecated.rst:216:`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente
Documentation/translations/sp_SP/process/deprecated.rst-217-a la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`).
--
arch/arm/kernel/entry-armv.S=512=ENTRY(__switch_to)
--
arch/arm/kernel/entry-armv.S-573-
arch/arm/kernel/entry-armv.S:574: @ When CONFIG_THREAD_INFO_IN_TASK=n, the update of SP itself is what
arch/arm/kernel/entry-armv.S-575- @ effectuates the task switch, as that is what causes the observable
arch/arm/kernel/entry-armv.S-576- @ values of current and current_thread_info to change. When
arch/arm/kernel/entry-armv.S:577: @ CONFIG_THREAD_INFO_IN_TASK=y, setting current (and therefore
arch/arm/kernel/entry-armv.S-578- @ current_thread_info) is done explicitly, and the update of SP just
--
include/linux/sched.h=819=struct task_struct {
include/linux/sched.h:820:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-821- /*
--
include/linux/sched.h-1566-#endif
include/linux/sched.h:1567:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1568- /* A live task holds one reference: */
--
include/linux/sched.h=1949=union thread_union {
include/linux/sched.h-1950- struct task_struct task;
include/linux/sched.h:1951:#ifndef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1952- struct thread_info thread_info;
--
include/linux/sched.h-1956-
include/linux/sched.h:1957:#ifndef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1958-extern struct thread_info init_thread_info;
--
include/linux/sched.h=1961=extern unsigned long init_stack[THREAD_SIZE / sizeof(unsigned long)];
include/linux/sched.h-1962-
include/linux/sched.h:1963:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched.h-1964-# define task_thread_info(task) (&(task)->thread_info)
--
include/linux/sched/task_stack.h-13-
include/linux/sched/task_stack.h:14:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched/task_stack.h-15-
--
include/linux/sched/task_stack.h=56=static inline unsigned long *end_of_stack(const struct task_struct *p)
--
include/linux/sched/task_stack.h-66-
include/linux/sched/task_stack.h:67:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/sched/task_stack.h-68-static inline void *try_get_task_stack(struct task_struct *tsk)
--
include/linux/thread_info.h-16-
include/linux/thread_info.h:17:#ifdef CONFIG_THREAD_INFO_IN_TASK
include/linux/thread_info.h-18-/*
include/linux/thread_info.h:19: * For CONFIG_THREAD_INFO_IN_TASK kernels we need <asm/current.h> for the
include/linux/thread_info.h:20: * definition of current, but for !CONFIG_THREAD_INFO_IN_TASK kernels,
include/linux/thread_info.h-21- * including <asm/current.h> can cause a circular dependency on some platforms.
--
init/init_task.c=96=struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
init/init_task.c:97:#ifdef CONFIG_THREAD_INFO_IN_TASK
init/init_task.c-98- .thread_info = INIT_THREAD_INFO(init_task),
--
init/init_task.c=253=EXPORT_SYMBOL(init_task);
--
init/init_task.c-258- */
init/init_task.c:259:#ifndef CONFIG_THREAD_INFO_IN_TASK
init/init_task.c-260-struct thread_info init_thread_info __init_thread_info = INIT_THREAD_INFO(init_task);
--
kernel/fork.c=513=static void release_task_stack(struct task_struct *tsk)
--
kernel/fork.c-520-
kernel/fork.c:521:#ifdef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-522-void put_task_stack(struct task_struct *tsk)
--
kernel/fork.c=529=void free_task(struct task_struct *tsk)
--
kernel/fork.c-536-
kernel/fork.c:537:#ifndef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-538- /*
--
kernel/fork.c=909=static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
--
kernel/fork.c-927-
kernel/fork.c:928:#ifdef CONFIG_THREAD_INFO_IN_TASK
kernel/fork.c-929- refcount_set(&tsk->stack_refcount, 1);
]
|
| 38/2 |
2026/05/15 18:17 |
llm |
expert |
0m
Model:
Tokens:
input: 39533
output: 45
thoughts: 248
Thoughts: **Debugging a Potential Stack Pointer Discrepancy**
Okay, so I'm trying to figure out this stack pointer issue. My first instinct was to `grep` for the relevant config, but of course, it's not in the source tree under `.config`. That's a rookie mistake. However, I do remember that `THREAD_INFO_IN_TASK` is typically selected by ARM. So, I figured, `end_of_stack` *should* be the same as `task->stack`. Let's say `task->stack` is `82800000`, then `end_of_stack` must be `82800000`. But wait, I'm seeing `r2` as `8280001c`. This is strange.
Could `end_of_stack` actually be `8280001c`? Why would that be? It's bothering me... ah, of course! If `CONFIG_THREAD_INFO_IN_TASK` is NOT defined, then `end_of_stack` becomes `(unsigned long *)(task_thread_info(p) + 1)`. That's the key. I bet `sizeof(struct thread_info)` on ARM is `0x1c`. That makes perfect sense. Let me just quickly confirm `sizeof(struct thread_info)` for ARM to be sure.
|
| 39/2 |
2026/05/15 18:18 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:arch/arm/include/asm/thread_info.h IncludeLines:true Name:thread_info]
Results: map[SourceCode: 62: struct thread_info {
63: unsigned long flags; /* low level flags */
64: unsigned long syscall_work; /* SYSCALL_WORK_ flags */
65: u32 status; /* thread synchronous flags */
66: #ifdef CONFIG_SMP
67: u32 cpu; /* current CPU */
68: #endif
69: };
SourceFile:arch/x86/include/asm/thread_info.h]
|
| 40/2 |
2026/05/15 18:18 |
llm |
expert |
0m
Model:
Tokens:
input: 40281
output: 45
thoughts: 15
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Analyzing Architecture: x86 vs. ARM**
Okay, first glance, that design strongly suggests x86. I need to be absolutely certain though, so I'm not making any assumptions based on just an initial assessment. The architectural nuances are crucial for performance optimization and debugging, and a misidentification at this stage is a huge waste of time. Let's make sure, what are the key identifiers? Is there any indication from the instruction set or memory model? Right, I need to immediately switch gears and perform a cross-reference. I'm going to quickly shift my focus and examine this again, but from the perspective of an ARM architecture. Let's see if this changes my perspective, is there some reason I'm missing some clues about the hardware design?
|
| 41/2 |
2026/05/15 18:18 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:arch/arm/include/asm/thread_info.h IncludeLines:true Name:thread_info]
Results: map[SourceCode: 62: struct thread_info {
63: unsigned long flags; /* low level flags */
64: unsigned long syscall_work; /* SYSCALL_WORK_ flags */
65: u32 status; /* thread synchronous flags */
66: #ifdef CONFIG_SMP
67: u32 cpu; /* current CPU */
68: #endif
69: };
SourceFile:arch/x86/include/asm/thread_info.h]
|
| 42/2 |
2026/05/15 18:18 |
llm |
expert |
0m
Model:
Tokens:
input: 40670
output: 28
thoughts: 27
Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience:
**Investigating the Architecture Return**
Okay, so the system unexpectedly reported x86. That's not what I anticipated. Time to dig in and see what's happening. My immediate instinct is to check the low-level architecture-specific thread information. The likely culprit or point of mis-identification is at the assembly level, since the arch is reporting something I don't expect. I'm going to jump into `arch/arm/include/asm/thread_info.h`. This file should give me insights into how the ARM kernel defines and manages its thread structures. I'm hoping to find the relevant macros or definitions that determine the reported architecture and look for the potential for a misconfiguration or misinterpretation there. I'm expecting to see something related to the CPU ID, the MMU, or some other hardware context that could be influencing the kernel's perception of the platform. I need to understand how the thread context is initialized and which variables or registers are used to determine and report the architecture type. That's my starting point.
|
| 43/2 |
2026/05/15 18:18 |
tool |
read-file |
0m
Args: map[File:arch/arm/include/asm/thread_info.h]
Results: map[Contents:/* SPDX-License-Identifier: GPL-2.0-only */
/*
* arch/arm/include/asm/thread_info.h
*
* Copyright (C) 2002 Russell King.
*/
#ifndef __ASM_ARM_THREAD_INFO_H
#define __ASM_ARM_THREAD_INFO_H
#ifdef __KERNEL__
#include <linux/compiler.h>
#include <asm/fpstate.h>
#include <asm/page.h>
#ifdef CONFIG_KASAN
/*
* KASan uses a lot of extra stack space so the thread size order needs to
* be increased.
*/
#define THREAD_SIZE_ORDER 2
#else
#define THREAD_SIZE_ORDER 1
#endif
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
#define THREAD_START_SP (THREAD_SIZE - 8)
#ifdef CONFIG_VMAP_STACK
#define THREAD_ALIGN (2 * THREAD_SIZE)
#else
#define THREAD_ALIGN THREAD_SIZE
#endif
#define OVERFLOW_STACK_SIZE SZ_4K
#ifndef __ASSEMBLY__
struct task_struct;
DECLARE_PER_CPU(struct task_struct *, __entry_task);
#include <asm/types.h>
#include <asm/traps.h>
struct cpu_context_save {
__u32 r4;
__u32 r5;
__u32 r6;
__u32 r7;
__u32 r8;
__u32 r9;
__u32 sl;
__u32 fp;
__u32 sp;
__u32 pc;
__u32 extra[2]; /* Xscale 'acc' register, etc */
};
/*
* low level task data that entry.S needs immediate access to.
* __switch_to() assumes cpu_context follows immediately after cpu_domain.
*/
struct thread_info {
unsigned long flags; /* low level flags */
int preempt_count; /* 0 => preemptable, <0 => bug */
__u32 cpu; /* cpu */
__u32 cpu_domain; /* cpu domain */
struct cpu_context_save cpu_context; /* cpu context */
__u32 abi_syscall; /* ABI type and syscall nr */
unsigned long tp_value[2]; /* TLS registers */
union fp_state fpstate __attribute__((aligned(8)));
union vfp_state vfpstate;
#ifdef CONFIG_ARM_THUMBEE
unsigned long thumbee_state; /* ThumbEE Handler Base register */
#endif
};
#define INIT_THREAD_INFO(tsk) \
{ \
.flags = 0, \
.preempt_count = INIT_PREEMPT_COUNT, \
}
static inline struct task_struct *thread_task(struct thread_info* ti)
{
return (struct task_struct *)ti;
}
#define thread_saved_pc(tsk) \
((unsigned long)(task_thread_info(tsk)->cpu_context.pc))
#define thread_saved_sp(tsk) \
((unsigned long)(task_thread_info(tsk)->cpu_context.sp))
#ifndef CONFIG_THUMB2_KERNEL
#define thread_saved_fp(tsk) \
((unsigned long)(task_thread_info(tsk)->cpu_context.fp))
#else
#define thread_saved_fp(tsk) \
((unsigned long)(task_thread_info(tsk)->cpu_context.r7))
#endif
extern void iwmmxt_task_disable(struct thread_info *);
extern void iwmmxt_task_copy(struct thread_info *, void *);
extern void iwmmxt_task_restore(struct thread_info *, void *);
extern void iwmmxt_task_release(struct thread_info *);
extern void iwmmxt_task_switch(struct thread_info *);
extern int iwmmxt_undef_handler(struct pt_regs *, u32);
static inline void register_iwmmxt_undef_handler(void)
{
static struct undef_hook iwmmxt_undef_hook = {
.instr_mask = 0x0c000e00,
.instr_val = 0x0c000000,
.cpsr_mask = MODE_MASK | PSR_T_BIT,
.cpsr_val = USR_MODE,
.fn = iwmmxt_undef_handler,
};
register_undef_hook(&iwmmxt_undef_hook);
}
extern void vfp_sync_hwstate(struct thread_info *);
extern void vfp_flush_hwstate(struct thread_info *);
struct user_vfp;
struct user_vfp_exc;
extern int vfp_preserve_user_clear_hwstate(struct user_vfp *,
struct user_vfp_exc *);
extern int vfp_restore_user_hwstate(struct user_vfp *,
struct user_vfp_exc *);
#endif
/*
* thread information flags:
* TIF_USEDFPU - FPU was used by this task this quantum (SMP)
* TIF_POLLING_NRFLAG - true if poll_idle() is polling TIF_NEED_RESCHED
*
* Any bit in the range of 0..15 will cause do_work_pending() to be invoked.
*/
#define TIF_SIGPENDING 0 /* signal pending */
#define TIF_NEED_RESCHED 1 /* rescheduling necessary */
#define TIF_NOTIFY_RESUME 2 /* callback before returning to user */
#define TIF_UPROBE 3 /* breakpointed or singlestepping */
#define TIF_NOTIFY_SIGNAL 4 /* signal notifications exist */
#define TIF_USING_IWMMXT 17
#define TIF_MEMDIE 18 /* is terminating due to OOM killer */
#define TIF_RESTORE_SIGMASK 19
#define TIF_SYSCALL_TRACE 20 /* syscall trace active */
#define TIF_SYSCALL_AUDIT 21 /* syscall auditing active */
#define TIF_SYSCALL_TRACEPOINT 22 /* syscall tracepoint instrumentation */
#define TIF_SECCOMP 23 /* seccomp syscall filtering active */
#define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
#define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
#define _TIF_UPROBE (1 << TIF_UPROBE)
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SYSCALL_TRACEPOINT (1 << TIF_SYSCALL_TRACEPOINT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
#define _TIF_NOTIFY_SIGNAL (1 << TIF_NOTIFY_SIGNAL)
#define _TIF_USING_IWMMXT (1 << TIF_USING_IWMMXT)
/* Checks for any syscall work in entry-common.S */
#define _TIF_SYSCALL_WORK (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
_TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP)
/*
* Change these and you break ASM code in entry-common.S
*/
#define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
_TIF_NOTIFY_RESUME | _TIF_UPROBE | \
_TIF_NOTIFY_SIGNAL)
#endif /* __KERNEL__ */
#endif /* __ASM_ARM_THREAD_INFO_H */
]
|
| 44/2 |
2026/05/15 18:18 |
llm |
expert |
0m
Model:
Tokens:
input: 42968
output: 23
thoughts: 426
Thoughts: **Analyzing the ARM `struct thread_info`**
Okay, so I'm looking at the `struct thread_info` definition for ARM, and immediately a few things jump out. The layout is: `flags`, `preempt_count`, `cpu`, `cpu_domain`, a `cpu_context_save`, `abi_syscall`, `tp_value`, `fpstate`, and `vfpstate`, with a potential `thumbee_state` depending on the config. My initial thought is that the size of this structure has to be considerably more than the seemingly random value of `0x1c` I recall seeing elsewhere. Let's do the math. `flags`, `preempt_count`, `cpu`, `cpu_domain`, and `abi_syscall` are all 4 bytes each, `tp_value` is 8, and the `cpu_context` is the big one, at 44 bytes. Doing the quick math the base size here is 72 bytes or `0x48`. Then there's `fpstate` and `vfpstate`, adding to that size. So, yeah, it's quite a large structure, much larger than what I initially thought.
However, I'm now remembering that the kernel configuration might drastically alter this. If `CONFIG_THREAD_INFO_IN_TASK` is enabled, then I seem to recall that the `thread_info` structure is drastically reduced, perhaps only containing things like `flags`, `syscall_work`, `status`, and `cpu`. I seem to recall setting this config in a previous Kconfig file. I better check `arch/arm/Kconfig` again to make sure that I'm not missing anything.
|
| 45/2 |
2026/05/15 18:18 |
tool |
grepper |
0m
Args: map[Expression:select THREAD_INFO_IN_TASK]
Results: map[Output:arch/arm/Kconfig=2=config ARM
--
arch/arm/Kconfig-156- select SYS_SUPPORTS_APM_EMULATION
arch/arm/Kconfig:157: select THREAD_INFO_IN_TASK
arch/arm/Kconfig-158- select TIMER_OF if OF
--
arch/arm64/Kconfig=2=config ARM64
--
arch/arm64/Kconfig-278- select SYSCTL_EXCEPTION_TRACE
arch/arm64/Kconfig:279: select THREAD_INFO_IN_TASK
arch/arm64/Kconfig-280- select HAVE_ARCH_USERFAULTFD_MINOR if USERFAULTFD
--
arch/parisc/Kconfig=2=config PARISC
--
arch/parisc/Kconfig-80- select CPU_NO_EFFICIENT_FFS
arch/parisc/Kconfig:81: select THREAD_INFO_IN_TASK
arch/parisc/Kconfig-82- select MMU_GATHER_RCU_TABLE_FREE
--
arch/powerpc/Kconfig=118=config PPC
--
arch/powerpc/Kconfig-327- select SYSCTL_EXCEPTION_TRACE
arch/powerpc/Kconfig:328: select THREAD_INFO_IN_TASK
arch/powerpc/Kconfig-329- select TRACE_IRQFLAGS_SUPPORT
--
arch/riscv/Kconfig=13=config RISCV
--
arch/riscv/Kconfig-224- select SYSCTL_EXCEPTION_TRACE
arch/riscv/Kconfig:225: select THREAD_INFO_IN_TASK
arch/riscv/Kconfig-226- select TRACE_IRQFLAGS_SUPPORT
--
arch/s390/Kconfig=78=config S390
--
arch/s390/Kconfig-282- select SYSTEM_DATA_VERIFICATION if KEXEC_SIG
arch/s390/Kconfig:283: select THREAD_INFO_IN_TASK
arch/s390/Kconfig-284- select TRACE_IRQFLAGS_SUPPORT
--
arch/um/Kconfig=5=config UML
--
arch/um/Kconfig-42- select HAVE_SYSCALL_TRACEPOINTS
arch/um/Kconfig:43: select THREAD_INFO_IN_TASK
arch/um/Kconfig-44- select SPARSE_IRQ
--
arch/x86/Kconfig=58=config X86
--
arch/x86/Kconfig-322- select SYSCTL_EXCEPTION_TRACE
arch/x86/Kconfig:323: select THREAD_INFO_IN_TASK
arch/x86/Kconfig-324- select TRACE_IRQFLAGS_SUPPORT
]
|
| 46/2 |
2026/05/15 18:18 |
llm |
expert |
0m
Model:
Tokens:
input: 44492
output: 19
thoughts: 544
Thoughts: **Analyzing a Kernel Panic in the ARM Architecture**
Okay, so I'm looking at this kernel panic related to `task_stack_end_corrupted` on an ARM system. The code's telling me that `arch/arm/Kconfig` selects `THREAD_INFO_IN_TASK`, so `end_of_stack` is `task->stack`. Right, that makes sense. If `end_of_stack` is `task->stack`, then the check `task_stack_end_corrupted` is effectively dereferencing `*(task->stack)`.
Now, the debugger is showing `task->stack` as `82800000`, and the check seems to be looking at `*(unsigned long *)0x82800000`. And then there's this register `r2` which is `8280001c`, I'm guessing `r2` is `task->stack + 0x1c`? Let's assume that for now.
I need to understand what `r0` and `r1` are in this context. They're `r0:82298d68` and `r1:822a7804`. Unfortunately, I don't have the kernel binary to disassemble `__schedule` and look at what those registers represent, which is frustrating. But I can make some educated guesses.
If `task_stack_end_corrupted(prev)` is panicking, the fundamental issue is that `*(task->stack)` is not equal to `STACK_END_MAGIC`. Why would that be? Well, stacks grow downwards, right? So if there's a stack overflow, the overflow would write *below* `task->stack`, overwriting the magic value. So, likely a stack overflow.
The interesting bit is that this is happening on `swapper/0`, which is the idle thread. How can the idle thread's stack overflow? The call trace seems pretty shallow: `start_kernel` -> `rest_init` -> `cpu_startup_entry` -> `do_idle` -> `schedule_idle` -> `__schedule` -> `schedule_debug`. There isn't much depth, so where would the overflow come from?
Wait a second, there's a tainted flag: `Tainted: [L]=SOFTLOCKUP`. That's the key. A soft lockup means the CPU got stuck in a loop with interrupts disabled, or in a loop within an interrupt context. The CPU was stuck, hence, the watchdog couldn't be updated. The watchdog prints a warning and a stack trace when a soft lockup is detected.
Now, if a soft lockup was detected, the watchdog timer interrupt must have fired. This interrupt handler runs on either the IRQ stack or the task stack. Now, in the ARM architecture, does it use a separate IRQ stack? It could be the interrupt handler is overflowing the stack while in the idle task, overwriting the magic value.
|
| 47/2 |
2026/05/15 18:19 |
tool |
grepper |
0m
Args: map[Expression:IRQ_STACK_SIZE]
Results: map[Output:Documentation/arch/x86/kernel-stacks.rst=23=specialized stacks contain no useful data. The main CPU stacks are:
Documentation/arch/x86/kernel-stacks.rst-24-
Documentation/arch/x86/kernel-stacks.rst:25:* Interrupt stack. IRQ_STACK_SIZE
Documentation/arch/x86/kernel-stacks.rst-26-
--
arch/arm64/include/asm/memory.h-139-
arch/arm64/include/asm/memory.h:140:#define IRQ_STACK_SIZE THREAD_SIZE
arch/arm64/include/asm/memory.h-141-
--
arch/arm64/include/asm/sdei.h-9-
arch/arm64/include/asm/sdei.h:10:#define SDEI_STACK_SIZE IRQ_STACK_SIZE
arch/arm64/include/asm/sdei.h-11-
--
arch/arm64/include/asm/stacktrace.h=25=static inline struct stack_info stackinfo_get_irq(void)
--
arch/arm64/include/asm/stacktrace.h-27- unsigned long low = (unsigned long)raw_cpu_read(irq_stack_ptr);
arch/arm64/include/asm/stacktrace.h:28: unsigned long high = low + IRQ_STACK_SIZE;
arch/arm64/include/asm/stacktrace.h-29-
--
arch/arm64/kernel/entry.S=874=SYM_FUNC_START(call_on_irq_stack)
--
arch/arm64/kernel/entry.S-888- /* Move to the new stack and call the function there */
arch/arm64/kernel/entry.S:889: add sp, x16, #IRQ_STACK_SIZE
arch/arm64/kernel/entry.S-890- restore_irq x9
--
arch/arm64/kernel/irq.c=54=static void __init init_irq_stacks(void)
--
arch/arm64/kernel/irq.c-59- for_each_possible_cpu(cpu) {
arch/arm64/kernel/irq.c:60: p = arch_alloc_vmap_stack(IRQ_STACK_SIZE, early_cpu_to_node(cpu));
arch/arm64/kernel/irq.c-61- per_cpu(irq_stack_ptr, cpu) = p;
--
arch/arm64/kernel/traps.c=903=void __noreturn panic_bad_stack(struct pt_regs *regs, unsigned long esr, unsigned long far)
--
arch/arm64/kernel/traps.c-917- pr_emerg("IRQ stack: [0x%016lx..0x%016lx]\n",
arch/arm64/kernel/traps.c:918: irq_stk, irq_stk + IRQ_STACK_SIZE);
arch/arm64/kernel/traps.c-919- pr_emerg("Overflow stack: [0x%016lx..0x%016lx]\n",
--
arch/loongarch/include/asm/irq.h-10-
arch/loongarch/include/asm/irq.h:11:#define IRQ_STACK_SIZE THREAD_SIZE
arch/loongarch/include/asm/irq.h:12:#define IRQ_STACK_START (IRQ_STACK_SIZE - 16)
arch/loongarch/include/asm/irq.h-13-
--
arch/loongarch/include/asm/irq.h=30=static inline bool on_irq_stack(int cpu, unsigned long sp)
--
arch/loongarch/include/asm/irq.h-32- unsigned long low = per_cpu(irq_stack, cpu);
arch/loongarch/include/asm/irq.h:33: unsigned long high = low + IRQ_STACK_SIZE;
arch/loongarch/include/asm/irq.h-34-
--
arch/loongarch/kernel/asm-offsets.c=83=static void __used output_thread_info_defines(void)
--
arch/loongarch/kernel/asm-offsets.c-93- DEFINE(_THREAD_MASK, THREAD_MASK);
arch/loongarch/kernel/asm-offsets.c:94: DEFINE(_IRQ_STACK_SIZE, IRQ_STACK_SIZE);
arch/loongarch/kernel/asm-offsets.c-95- DEFINE(_IRQ_STACK_START, IRQ_STACK_START);
--
arch/loongarch/kernel/irq.c=102=void __init init_IRQ(void)
--
arch/loongarch/kernel/irq.c-104- int i;
arch/loongarch/kernel/irq.c:105: unsigned int order = get_order(IRQ_STACK_SIZE);
arch/loongarch/kernel/irq.c-106- struct page *page;
--
arch/loongarch/kernel/irq.c-121- pr_debug("CPU%d IRQ stack at 0x%lx - 0x%lx\n", i,
arch/loongarch/kernel/irq.c:122: per_cpu(irq_stack, i), per_cpu(irq_stack, i) + IRQ_STACK_SIZE);
arch/loongarch/kernel/irq.c-123- }
--
arch/mips/include/asm/irq.h-18-
arch/mips/include/asm/irq.h:19:#define IRQ_STACK_SIZE THREAD_SIZE
arch/mips/include/asm/irq.h:20:#define IRQ_STACK_START (IRQ_STACK_SIZE - 16)
arch/mips/include/asm/irq.h-21-
--
arch/mips/include/asm/irq.h=38=static inline bool on_irq_stack(int cpu, unsigned long sp)
--
arch/mips/include/asm/irq.h-40- unsigned long low = (unsigned long)irq_stack[cpu];
arch/mips/include/asm/irq.h:41: unsigned long high = low + IRQ_STACK_SIZE;
arch/mips/include/asm/irq.h-42-
--
arch/mips/kernel/asm-offsets.c=103=void output_thread_info_defines(void)
--
arch/mips/kernel/asm-offsets.c-114- DEFINE(_THREAD_MASK, THREAD_MASK);
arch/mips/kernel/asm-offsets.c:115: DEFINE(_IRQ_STACK_SIZE, IRQ_STACK_SIZE);
arch/mips/kernel/asm-offsets.c-116- DEFINE(_IRQ_STACK_START, IRQ_STACK_START);
--
arch/mips/kernel/irq.c=53=void __init init_IRQ(void)
--
arch/mips/kernel/irq.c-55- int i;
arch/mips/kernel/irq.c:56: unsigned int order = get_order(IRQ_STACK_SIZE);
arch/mips/kernel/irq.c-57-
--
arch/mips/kernel/irq.c-70- pr_debug("CPU%d IRQ stack at 0x%p - 0x%p\n", i,
arch/mips/kernel/irq.c:71: irq_stack[i], irq_stack[i] + IRQ_STACK_SIZE);
arch/mips/kernel/irq.c-72- }
--
arch/parisc/kernel/irq.c=346=static inline int eirr_to_irq(unsigned long eirr)
--
arch/parisc/kernel/irq.c-356-#ifdef CONFIG_64BIT
arch/parisc/kernel/irq.c:357:#define IRQ_STACK_SIZE (4096 << 4) /* 64k irq stack size */
arch/parisc/kernel/irq.c-358-#else
arch/parisc/kernel/irq.c:359:#define IRQ_STACK_SIZE (4096 << 3) /* 32k irq stack size */
arch/parisc/kernel/irq.c-360-#endif
--
arch/parisc/kernel/irq.c=362=union irq_stack_union {
arch/parisc/kernel/irq.c:363: unsigned long stack[IRQ_STACK_SIZE/sizeof(unsigned long)];
arch/parisc/kernel/irq.c-364- volatile unsigned int slock[4];
--
arch/parisc/kernel/irq.c=376=static inline void stack_overflow_check(struct pt_regs *regs)
--
arch/parisc/kernel/irq.c-409-
arch/parisc/kernel/irq.c:410: if (likely(stack_usage < (IRQ_STACK_SIZE - STACK_MARGIN)))
arch/parisc/kernel/irq.c-411- return;
--
arch/parisc/kernel/irq.c-414- "(sp:%lx, stk bottom-top:%lx-%lx)\n",
arch/parisc/kernel/irq.c:415: current->comm, sp, stack_start, stack_start + IRQ_STACK_SIZE);
arch/parisc/kernel/irq.c-416- goto panic_check;
--
arch/riscv/include/asm/thread_info.h-37-
arch/riscv/include/asm/thread_info.h:38:#define IRQ_STACK_SIZE THREAD_SIZE
arch/riscv/include/asm/thread_info.h-39-
--
arch/riscv/kernel/entry.S=381=SYM_FUNC_START(call_on_irq_stack)
--
arch/riscv/kernel/entry.S-393- load_per_cpu t0, irq_stack_ptr, t1
arch/riscv/kernel/entry.S:394: li t1, IRQ_STACK_SIZE
arch/riscv/kernel/entry.S-395- add sp, t0, t1
--
arch/riscv/kernel/irq.c=93=static void init_irq_stacks(void)
--
arch/riscv/kernel/irq.c-98- for_each_possible_cpu(cpu) {
arch/riscv/kernel/irq.c:99: p = arch_alloc_vmap_stack(IRQ_STACK_SIZE, cpu_to_node(cpu));
arch/riscv/kernel/irq.c-100- per_cpu(irq_stack_ptr, cpu) = p;
--
arch/riscv/kernel/irq.c-103-#else
arch/riscv/kernel/irq.c:104:/* irq stack only needs to be 16 byte aligned - not IRQ_STACK_SIZE aligned. */
arch/riscv/kernel/irq.c:105:DEFINE_PER_CPU_ALIGNED(ulong [IRQ_STACK_SIZE/sizeof(ulong)], irq_stack);
arch/riscv/kernel/irq.c-106-
--
arch/x86/include/asm/page_32_types.h-24-
arch/x86/include/asm/page_32_types.h:25:#define IRQ_STACK_SIZE THREAD_SIZE
arch/x86/include/asm/page_32_types.h-26-
--
arch/x86/include/asm/page_64_types.h-21-#define IRQ_STACK_ORDER (2 + KASAN_STACK_ORDER)
arch/x86/include/asm/page_64_types.h:22:#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
arch/x86/include/asm/page_64_types.h-23-
--
arch/x86/include/asm/processor.h=414=struct irq_stack {
arch/x86/include/asm/processor.h:415: char stack[IRQ_STACK_SIZE];
arch/x86/include/asm/processor.h:416:} __aligned(IRQ_STACK_SIZE);
arch/x86/include/asm/processor.h-417-
--
arch/x86/kernel/dumpstack_64.c=135=static __always_inline bool in_irq_stack(unsigned long *stack, struct stack_info *info)
--
arch/x86/kernel/dumpstack_64.c-145- end++;
arch/x86/kernel/dumpstack_64.c:146: begin = end - (IRQ_STACK_SIZE / sizeof(long));
arch/x86/kernel/dumpstack_64.c-147-
--
arch/x86/kernel/irq_64.c=36=static int map_irq_stack(unsigned int cpu)
--
arch/x86/kernel/irq_64.c-38- char *stack = (char *)per_cpu_ptr(&irq_stack_backing_store, cpu);
arch/x86/kernel/irq_64.c:39: struct page *pages[IRQ_STACK_SIZE / PAGE_SIZE];
arch/x86/kernel/irq_64.c-40- void *va;
--
arch/x86/kernel/irq_64.c-42-
arch/x86/kernel/irq_64.c:43: for (i = 0; i < IRQ_STACK_SIZE / PAGE_SIZE; i++) {
arch/x86/kernel/irq_64.c-44- phys_addr_t pa = per_cpu_ptr_to_phys(stack + (i << PAGE_SHIFT));
--
arch/x86/kernel/irq_64.c-48-
arch/x86/kernel/irq_64.c:49: va = vmap(pages, IRQ_STACK_SIZE / PAGE_SIZE, VM_MAP, PAGE_KERNEL);
arch/x86/kernel/irq_64.c-50- if (!va)
--
arch/x86/kernel/irq_64.c-53- /* Store actual TOS to avoid adjustment in the hotpath */
arch/x86/kernel/irq_64.c:54: per_cpu(hardirq_stack_ptr, cpu) = va + IRQ_STACK_SIZE - 8;
arch/x86/kernel/irq_64.c-55- return 0;
--
arch/x86/kernel/irq_64.c=62=static int map_irq_stack(unsigned int cpu)
--
arch/x86/kernel/irq_64.c-66- /* Store actual TOS to avoid adjustment in the hotpath */
arch/x86/kernel/irq_64.c:67: per_cpu(hardirq_stack_ptr, cpu) = va + IRQ_STACK_SIZE - 8;
arch/x86/kernel/irq_64.c-68- return 0;
]
|
| 48/2 |
2026/05/15 18:19 |
llm |
expert |
0m
Model:
Tokens:
input: 49640
output: 18
thoughts: 65
Thoughts: **ARM32 and Interrupts - A Quick Investigation**
Okay, so I was looking through some code, specifically using `grep`, and I noticed something interesting about the ARM32 architecture. The `IRQ_STACK_SIZE` wasn't showing up in the grep results. That immediately piqued my interest. My initial thought was, "Wait, does ARM32 forgo a dedicated interrupt stack? Does it actually use the task stack for interrupt handling?"
This raises some interesting implications for interrupt latency and context switching overhead. To verify this, I think I need to dig deeper. I'm going to check the source code itself, likely in `arch/arm/kernel/irq.c` or maybe `arch/arm/include/asm/irq.h`. These files should give me the authoritative answer on how ARM32 handles its interrupt stack and related configurations. I need to understand this to make an informed decision and proceed further.
|
| 49/2 |
2026/05/15 18:19 |
tool |
grepper |
0m
Args: map[Expression:irq_stack]
Results: map[Output:
Full output is too long, showing 500 out of 828 lines.
Use more precise expression if possible.
[arch/arm/kernel/entry-armv.S-43- mov r1, sp
arch/arm/kernel/entry-armv.S:44: ldr_this_cpu r2, irq_stack_ptr, r2, r3
arch/arm/kernel/entry-armv.S-45- .if \from_user == 0
--
arch/arm/kernel/entry-v7m.S=36=__irq_entry:
--
arch/arm/kernel/entry-v7m.S-42- mov r0, sp
arch/arm/kernel/entry-v7m.S:43: ldr_this_cpu sp, irq_stack_ptr, r1, r2
arch/arm/kernel/entry-v7m.S-44-
--
arch/arm/kernel/irq.c-39-#include <asm/outercache.h>
arch/arm/kernel/irq.c:40:#include <asm/softirq_stack.h>
arch/arm/kernel/irq.c-41-#include <asm/exception.h>
--
arch/arm/kernel/irq.c=48=unsigned long irq_err_count;
--
arch/arm/kernel/irq.c-51-
arch/arm/kernel/irq.c:52:asmlinkage DEFINE_PER_CPU_READ_MOSTLY(u8 *, irq_stack_ptr);
arch/arm/kernel/irq.c-53-
arch/arm/kernel/irq.c:54:static void __init init_irq_stacks(void)
arch/arm/kernel/irq.c-55-{
--
arch/arm/kernel/irq.c-69- break;
arch/arm/kernel/irq.c:70: per_cpu(irq_stack_ptr, cpu) = &stack[THREAD_SIZE];
arch/arm/kernel/irq.c-71- }
--
arch/arm/kernel/irq.c=80=void do_softirq_own_stack(void)
--
arch/arm/kernel/irq.c-82- call_with_stack(____do_softirq, NULL,
arch/arm/kernel/irq.c:83: __this_cpu_read(irq_stack_ptr));
arch/arm/kernel/irq.c-84-}
--
arch/arm/kernel/irq.c=125=void __init init_IRQ(void)
--
arch/arm/kernel/irq.c-129-#ifdef CONFIG_IRQSTACKS
arch/arm/kernel/irq.c:130: init_irq_stacks();
arch/arm/kernel/irq.c-131-#endif
--
arch/arm/kernel/traps.c=890=void __init early_trap_init(void *vectors_base)
--
arch/arm/kernel/traps.c-901-
arch/arm/kernel/traps.c:902:DECLARE_PER_CPU(u8 *, irq_stack_ptr);
arch/arm/kernel/traps.c-903-
--
arch/arm/kernel/traps.c=921=asmlinkage void handle_bad_stack(struct pt_regs *regs)
--
arch/arm/kernel/traps.c-924-#ifdef CONFIG_IRQSTACKS
arch/arm/kernel/traps.c:925: unsigned long irq_stk = (unsigned long)raw_cpu_read(irq_stack_ptr);
arch/arm/kernel/traps.c-926-#endif
--
arch/arm64/include/asm/exception.h=49=asmlinkage void el0t_32_error_handler(struct pt_regs *regs);
arch/arm64/include/asm/exception.h-50-
arch/arm64/include/asm/exception.h:51:asmlinkage void call_on_irq_stack(struct pt_regs *regs,
arch/arm64/include/asm/exception.h-52- void (*func)(struct pt_regs *));
--
arch/arm64/include/asm/stacktrace.h=20=extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk,
--
arch/arm64/include/asm/stacktrace.h-22-
arch/arm64/include/asm/stacktrace.h:23:DECLARE_PER_CPU(unsigned long *, irq_stack_ptr);
arch/arm64/include/asm/stacktrace.h-24-
arch/arm64/include/asm/stacktrace.h=25=static inline struct stack_info stackinfo_get_irq(void)
arch/arm64/include/asm/stacktrace.h-26-{
arch/arm64/include/asm/stacktrace.h:27: unsigned long low = (unsigned long)raw_cpu_read(irq_stack_ptr);
arch/arm64/include/asm/stacktrace.h-28- unsigned long high = low + IRQ_STACK_SIZE;
--
arch/arm64/include/asm/stacktrace.h-35-
arch/arm64/include/asm/stacktrace.h:36:static inline bool on_irq_stack(unsigned long sp, unsigned long size)
arch/arm64/include/asm/stacktrace.h-37-{
--
arch/arm64/kernel/entry-common.c=129=static void do_interrupt_handler(struct pt_regs *regs,
--
arch/arm64/kernel/entry-common.c-134- if (on_thread_stack())
arch/arm64/kernel/entry-common.c:135: call_on_irq_stack(regs, handler);
arch/arm64/kernel/entry-common.c-136- else
--
arch/arm64/kernel/entry.S=866=NOKPROBE(ret_from_fork)
--
arch/arm64/kernel/entry.S-868-/*
arch/arm64/kernel/entry.S:869: * void call_on_irq_stack(struct pt_regs *regs,
arch/arm64/kernel/entry.S-870- * void (*func)(struct pt_regs *));
--
arch/arm64/kernel/entry.S-873- */
arch/arm64/kernel/entry.S:874:SYM_FUNC_START(call_on_irq_stack)
arch/arm64/kernel/entry.S-875- save_and_disable_daif x9
--
arch/arm64/kernel/entry.S-885-
arch/arm64/kernel/entry.S:886: ldr_this_cpu x16, irq_stack_ptr, x17
arch/arm64/kernel/entry.S-887-
--
arch/arm64/kernel/entry.S-902- ret
arch/arm64/kernel/entry.S:903:SYM_FUNC_END(call_on_irq_stack)
arch/arm64/kernel/entry.S:904:NOKPROBE(call_on_irq_stack)
arch/arm64/kernel/entry.S-905-
--
arch/arm64/kernel/irq.c-25-#include <asm/numa.h>
arch/arm64/kernel/irq.c:26:#include <asm/softirq_stack.h>
arch/arm64/kernel/irq.c-27-#include <asm/stacktrace.h>
--
arch/arm64/kernel/irq.c=31=DEFINE_PER_CPU(struct nmi_ctx, nmi_contexts);
arch/arm64/kernel/irq.c-32-
arch/arm64/kernel/irq.c:33:DEFINE_PER_CPU(unsigned long *, irq_stack_ptr);
arch/arm64/kernel/irq.c-34-
--
arch/arm64/kernel/irq.c=42=static void init_irq_scs(void)
--
arch/arm64/kernel/irq.c-53-
arch/arm64/kernel/irq.c:54:static void __init init_irq_stacks(void)
arch/arm64/kernel/irq.c-55-{
--
arch/arm64/kernel/irq.c-60- p = arch_alloc_vmap_stack(IRQ_STACK_SIZE, early_cpu_to_node(cpu));
arch/arm64/kernel/irq.c:61: per_cpu(irq_stack_ptr, cpu) = p;
arch/arm64/kernel/irq.c-62- }
--
arch/arm64/kernel/irq.c=71=void do_softirq_own_stack(void)
arch/arm64/kernel/irq.c-72-{
arch/arm64/kernel/irq.c:73: call_on_irq_stack(NULL, ____do_softirq);
arch/arm64/kernel/irq.c-74-}
--
arch/arm64/kernel/irq.c=110=void __init init_IRQ(void)
arch/arm64/kernel/irq.c-111-{
arch/arm64/kernel/irq.c:112: init_irq_stacks();
arch/arm64/kernel/irq.c-113- init_irq_scs();
--
arch/arm64/kernel/ptrace.c=122=static bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
--
arch/arm64/kernel/ptrace.c-125- (kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1))) ||
arch/arm64/kernel/ptrace.c:126: on_irq_stack(addr, sizeof(unsigned long));
arch/arm64/kernel/ptrace.c-127-}
--
arch/arm64/kernel/traps.c=903=void __noreturn panic_bad_stack(struct pt_regs *regs, unsigned long esr, unsigned long far)
--
arch/arm64/kernel/traps.c-905- unsigned long tsk_stk = (unsigned long)current->stack;
arch/arm64/kernel/traps.c:906: unsigned long irq_stk = (unsigned long)this_cpu_read(irq_stack_ptr);
arch/arm64/kernel/traps.c-907- unsigned long ovf_stk = (unsigned long)this_cpu_ptr(overflow_stack);
--
arch/loongarch/include/asm/irq.h-13-
arch/loongarch/include/asm/irq.h:14:DECLARE_PER_CPU(unsigned long, irq_stack);
arch/loongarch/include/asm/irq.h-15-
--
arch/loongarch/include/asm/irq.h-20- * top ------------
arch/loongarch/include/asm/irq.h:21: * | task sp | <- irq_stack[cpu] + IRQ_STACK_START
arch/loongarch/include/asm/irq.h-22- * ------------
--
arch/loongarch/include/asm/irq.h-29-
arch/loongarch/include/asm/irq.h:30:static inline bool on_irq_stack(int cpu, unsigned long sp)
arch/loongarch/include/asm/irq.h-31-{
arch/loongarch/include/asm/irq.h:32: unsigned long low = per_cpu(irq_stack, cpu);
arch/loongarch/include/asm/irq.h-33- unsigned long high = low + IRQ_STACK_SIZE;
--
arch/loongarch/include/asm/stacktrace.h=25=struct stack_frame {
--
arch/loongarch/include/asm/stacktrace.h-29-
arch/loongarch/include/asm/stacktrace.h:30:bool in_irq_stack(unsigned long stack, struct stack_info *info);
arch/loongarch/include/asm/stacktrace.h-31-bool in_task_stack(unsigned long stack, struct task_struct *task, struct stack_info *info);
--
arch/loongarch/kernel/irq.c-23-
arch/loongarch/kernel/irq.c:24:DEFINE_PER_CPU(unsigned long, irq_stack);
arch/loongarch/kernel/irq.c-25-DEFINE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
--
arch/loongarch/kernel/irq.c=102=void __init init_IRQ(void)
--
arch/loongarch/kernel/irq.c-119-
arch/loongarch/kernel/irq.c:120: per_cpu(irq_stack, i) = (unsigned long)page_address(page);
arch/loongarch/kernel/irq.c-121- pr_debug("CPU%d IRQ stack at 0x%lx - 0x%lx\n", i,
arch/loongarch/kernel/irq.c:122: per_cpu(irq_stack, i), per_cpu(irq_stack, i) + IRQ_STACK_SIZE);
arch/loongarch/kernel/irq.c-123- }
--
arch/loongarch/kernel/process.c=235=unsigned long __get_wchan(struct task_struct *task)
--
arch/loongarch/kernel/process.c-257-
arch/loongarch/kernel/process.c:258:bool in_irq_stack(unsigned long stack, struct stack_info *info)
arch/loongarch/kernel/process.c-259-{
arch/loongarch/kernel/process.c-260- unsigned long nextsp;
arch/loongarch/kernel/process.c:261: unsigned long begin = (unsigned long)this_cpu_read(irq_stack);
arch/loongarch/kernel/process.c-262- unsigned long end = begin + IRQ_STACK_START;
--
arch/loongarch/kernel/process.c=296=int get_stack_info(unsigned long stack, struct task_struct *task,
--
arch/loongarch/kernel/process.c-309-
arch/loongarch/kernel/process.c:310: if (in_irq_stack(stack, info))
arch/loongarch/kernel/process.c-311- return 0;
--
arch/loongarch/kernel/traps.c=1099=asmlinkage void noinstr do_vint(struct pt_regs *regs, unsigned long sp)
--
arch/loongarch/kernel/traps.c-1106-
arch/loongarch/kernel/traps.c:1107: if (on_irq_stack(cpu, sp))
arch/loongarch/kernel/traps.c-1108- handle_loongarch_irq(regs);
arch/loongarch/kernel/traps.c-1109- else {
arch/loongarch/kernel/traps.c:1110: stack = per_cpu(irq_stack, cpu) + IRQ_STACK_START;
arch/loongarch/kernel/traps.c-1111-
--
arch/mips/include/asm/irq.h-21-
arch/mips/include/asm/irq.h:22:extern void *irq_stack[NR_CPUS];
arch/mips/include/asm/irq.h-23-
--
arch/mips/include/asm/irq.h-28- * top ------------
arch/mips/include/asm/irq.h:29: * | task sp | <- irq_stack[cpu] + IRQ_STACK_START
arch/mips/include/asm/irq.h-30- * ------------
--
arch/mips/include/asm/irq.h-37-
arch/mips/include/asm/irq.h:38:static inline bool on_irq_stack(int cpu, unsigned long sp)
arch/mips/include/asm/irq.h-39-{
arch/mips/include/asm/irq.h:40: unsigned long low = (unsigned long)irq_stack[cpu];
arch/mips/include/asm/irq.h-41- unsigned long high = low + IRQ_STACK_SIZE;
--
arch/mips/kernel/genex.S=160=NESTED(handle_int, PT_SIZE, sp)
--
arch/mips/kernel/genex.S-208-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
arch/mips/kernel/genex.S:209: lui k1, %hi(irq_stack)
arch/mips/kernel/genex.S-210-#else
arch/mips/kernel/genex.S:211: lui k1, %highest(irq_stack)
arch/mips/kernel/genex.S:212: daddiu k1, %higher(irq_stack)
arch/mips/kernel/genex.S-213- dsll k1, 16
arch/mips/kernel/genex.S:214: daddiu k1, %hi(irq_stack)
arch/mips/kernel/genex.S-215- dsll k1, 16
--
arch/mips/kernel/genex.S-218- LONG_ADDU k1, k0
arch/mips/kernel/genex.S:219: LONG_L t0, %lo(irq_stack)(k1)
arch/mips/kernel/genex.S-220-
--
arch/mips/kernel/genex.S=298=NESTED(except_vec_vi_handler, 0, sp)
--
arch/mips/kernel/genex.S-319-#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
arch/mips/kernel/genex.S:320: lui k1, %hi(irq_stack)
arch/mips/kernel/genex.S-321-#else
arch/mips/kernel/genex.S:322: lui k1, %highest(irq_stack)
arch/mips/kernel/genex.S:323: daddiu k1, %higher(irq_stack)
arch/mips/kernel/genex.S-324- dsll k1, 16
arch/mips/kernel/genex.S:325: daddiu k1, %hi(irq_stack)
arch/mips/kernel/genex.S-326- dsll k1, 16
--
arch/mips/kernel/genex.S-329- LONG_ADDU k1, k0
arch/mips/kernel/genex.S:330: LONG_L t0, %lo(irq_stack)(k1)
arch/mips/kernel/genex.S-331-
--
arch/mips/kernel/irq.c-28-
arch/mips/kernel/irq.c:29:void *irq_stack[NR_CPUS];
arch/mips/kernel/irq.c-30-
--
arch/mips/kernel/irq.c=53=void __init init_IRQ(void)
--
arch/mips/kernel/irq.c-68-
arch/mips/kernel/irq.c:69: irq_stack[i] = s;
arch/mips/kernel/irq.c-70- pr_debug("CPU%d IRQ stack at 0x%p - 0x%p\n", i,
arch/mips/kernel/irq.c:71: irq_stack[i], irq_stack[i] + IRQ_STACK_SIZE);
arch/mips/kernel/irq.c-72- }
--
arch/mips/kernel/process.c=544=unsigned long notrace unwind_stack_by_address(unsigned long stack_page,
--
arch/mips/kernel/process.c-548-{
arch/mips/kernel/process.c:549: unsigned long low, high, irq_stack_high;
arch/mips/kernel/process.c-550- struct mips_frame_info info;
--
arch/mips/kernel/process.c-562- low = stack_page;
arch/mips/kernel/process.c:563: if (!preemptible() && on_irq_stack(raw_smp_processor_id(), *sp)) {
arch/mips/kernel/process.c-564- high = stack_page + IRQ_STACK_START;
arch/mips/kernel/process.c:565: irq_stack_high = high;
arch/mips/kernel/process.c-566- } else {
arch/mips/kernel/process.c-567- high = stack_page + THREAD_SIZE - 32;
arch/mips/kernel/process.c:568: irq_stack_high = 0;
arch/mips/kernel/process.c-569- }
--
arch/mips/kernel/process.c-574- */
arch/mips/kernel/process.c:575: if (unlikely(*sp == irq_stack_high)) {
arch/mips/kernel/process.c-576- unsigned long task_sp = *(unsigned long *)*sp;
--
arch/mips/kernel/process.c=636=unsigned long unwind_stack(struct task_struct *task, unsigned long *sp,
--
arch/mips/kernel/process.c-642- for_each_possible_cpu(cpu) {
arch/mips/kernel/process.c:643: if (on_irq_stack(cpu, *sp)) {
arch/mips/kernel/process.c:644: stack_page = (unsigned long)irq_stack[cpu];
arch/mips/kernel/process.c-645- break;
--
arch/parisc/include/asm/hardirq.h=15=typedef struct {
--
arch/parisc/include/asm/hardirq.h-17- unsigned int kernel_stack_usage;
arch/parisc/include/asm/hardirq.h:18: unsigned int irq_stack_usage;
arch/parisc/include/asm/hardirq.h-19-#ifdef CONFIG_SMP
--
arch/parisc/kernel/irq.c-20-
arch/parisc/kernel/irq.c:21:#include <asm/softirq_stack.h>
arch/parisc/kernel/irq.c-22-#include <asm/smp.h>
--
arch/parisc/kernel/irq.c=131=int arch_show_interrupts(struct seq_file *p, int prec)
--
arch/parisc/kernel/irq.c-142- for_each_online_cpu(j)
arch/parisc/kernel/irq.c:143: seq_printf(p, "%10u ", irq_stats(j)->irq_stack_usage);
arch/parisc/kernel/irq.c-144- seq_puts(p, " Interrupt stack usage\n");
--
arch/parisc/kernel/irq.c=346=static inline int eirr_to_irq(unsigned long eirr)
--
arch/parisc/kernel/irq.c-361-
arch/parisc/kernel/irq.c:362:union irq_stack_union {
arch/parisc/kernel/irq.c-363- unsigned long stack[IRQ_STACK_SIZE/sizeof(unsigned long)];
--
arch/parisc/kernel/irq.c-367-
arch/parisc/kernel/irq.c:368:static DEFINE_PER_CPU(union irq_stack_union, irq_stack_union) = {
arch/parisc/kernel/irq.c-369- .slock = { 1,1,1,1 },
--
arch/parisc/kernel/irq.c=376=static inline void stack_overflow_check(struct pt_regs *regs)
--
arch/parisc/kernel/irq.c-402- /* check irq stack usage */
arch/parisc/kernel/irq.c:403: stack_start = (unsigned long) &per_cpu(irq_stack_union, cpu).stack;
arch/parisc/kernel/irq.c-404- stack_usage = sp - stack_start;
arch/parisc/kernel/irq.c-405-
arch/parisc/kernel/irq.c:406: last_usage = &per_cpu(irq_stat.irq_stack_usage, cpu);
arch/parisc/kernel/irq.c-407- if (unlikely(stack_usage > *last_usage))
--
arch/parisc/kernel/irq.c=446=void call_on_stack(unsigned long p1, void *func, unsigned long new_stack);
arch/parisc/kernel/irq.c-447-
arch/parisc/kernel/irq.c:448:static void execute_on_irq_stack(void *func, unsigned long param1)
arch/parisc/kernel/irq.c-449-{
arch/parisc/kernel/irq.c:450: union irq_stack_union *union_ptr;
arch/parisc/kernel/irq.c:451: unsigned long irq_stack;
arch/parisc/kernel/irq.c:452: volatile unsigned int *irq_stack_in_use;
arch/parisc/kernel/irq.c-453-
arch/parisc/kernel/irq.c:454: union_ptr = &per_cpu(irq_stack_union, smp_processor_id());
arch/parisc/kernel/irq.c:455: irq_stack = (unsigned long) &union_ptr->stack;
arch/parisc/kernel/irq.c:456: irq_stack = ALIGN(irq_stack + sizeof(irq_stack_union.slock),
arch/parisc/kernel/irq.c-457- FRAME_ALIGN); /* align for stack frame usage */
--
arch/parisc/kernel/irq.c-462- */
arch/parisc/kernel/irq.c:463: irq_stack_in_use = (volatile unsigned int *)__ldcw_align(union_ptr);
arch/parisc/kernel/irq.c:464: if (!__ldcw(irq_stack_in_use)) {
arch/parisc/kernel/irq.c-465- void (*direct_call)(unsigned long p1) = func;
--
arch/parisc/kernel/irq.c-473- /* This is where we switch to the IRQ stack. */
arch/parisc/kernel/irq.c:474: call_on_stack(param1, func, irq_stack);
arch/parisc/kernel/irq.c-475-
arch/parisc/kernel/irq.c-476- /* free up irq stack usage. */
arch/parisc/kernel/irq.c:477: *irq_stack_in_use = 1;
arch/parisc/kernel/irq.c-478-}
--
arch/parisc/kernel/irq.c=481=void do_softirq_own_stack(void)
arch/parisc/kernel/irq.c-482-{
arch/parisc/kernel/irq.c:483: execute_on_irq_stack(__do_softirq, 0);
arch/parisc/kernel/irq.c-484-}
--
arch/parisc/kernel/irq.c=489=asmlinkage void do_cpu_irq_mask(struct pt_regs *regs)
--
arch/parisc/kernel/irq.c-529-#ifdef CONFIG_IRQSTACKS
arch/parisc/kernel/irq.c:530: execute_on_irq_stack(&generic_handle_irq, irq);
arch/parisc/kernel/irq.c-531-#else
--
arch/powerpc/kernel/irq.c-66-#include <asm/hw_irq.h>
arch/powerpc/kernel/irq.c:67:#include <asm/softirq_stack.h>
arch/powerpc/kernel/irq.c-68-#include <asm/ppc_asm.h>
--
arch/powerpc/kernel/irq_64.c-58-#include <asm/hw_irq.h>
arch/powerpc/kernel/irq_64.c:59:#include <asm/softirq_stack.h>
arch/powerpc/kernel/irq_64.c-60-#include <asm/ppc_asm.h>
--
arch/powerpc/kernel/process.c=2123=int get_unalign_ctl(struct task_struct *tsk, unsigned long adr)
--
arch/powerpc/kernel/process.c-2127-
arch/powerpc/kernel/process.c:2128:static inline int valid_irq_stack(unsigned long sp, struct task_struct *p,
arch/powerpc/kernel/process.c-2129- unsigned long nbytes)
--
arch/powerpc/kernel/process.c=2204=int validate_sp_size(unsigned long sp, struct task_struct *p,
--
arch/powerpc/kernel/process.c-2214-
arch/powerpc/kernel/process.c:2215: if (valid_irq_stack(sp, p, nbytes))
arch/powerpc/kernel/process.c-2216- return 1;
--
arch/riscv/include/asm/irq_stack.h-12-
arch/riscv/include/asm/irq_stack.h:13:DECLARE_PER_CPU(ulong *, irq_stack_ptr);
arch/riscv/include/asm/irq_stack.h-14-
arch/riscv/include/asm/irq_stack.h:15:asmlinkage void call_on_irq_stack(struct pt_regs *regs,
arch/riscv/include/asm/irq_stack.h-16- void (*func)(struct pt_regs *));
--
arch/riscv/include/asm/scs.h-16-/* Load the per-CPU IRQ shadow call stack to gp. */
arch/riscv/include/asm/scs.h:17:.macro scs_load_irq_stack tmp
arch/riscv/include/asm/scs.h-18- load_per_cpu gp, irq_shadow_call_stack_ptr, \tmp
--
arch/riscv/include/asm/scs.h-41-.endm
arch/riscv/include/asm/scs.h:42:.macro scs_load_irq_stack tmp
arch/riscv/include/asm/scs.h-43-.endm
--
arch/riscv/kernel/entry.S=372=SYM_CODE_END(ret_from_fork_user_asm)
--
arch/riscv/kernel/entry.S-375-/*
arch/riscv/kernel/entry.S:376: * void call_on_irq_stack(struct pt_regs *regs,
arch/riscv/kernel/entry.S-377- * void (*func)(struct pt_regs *));
--
arch/riscv/kernel/entry.S-380- */
arch/riscv/kernel/entry.S:381:SYM_FUNC_START(call_on_irq_stack)
arch/riscv/kernel/entry.S-382- /* Create a frame record to save ra and s0 (fp) */
--
arch/riscv/kernel/entry.S-389- scs_save_current
arch/riscv/kernel/entry.S:390: scs_load_irq_stack t0
arch/riscv/kernel/entry.S-391-
arch/riscv/kernel/entry.S-392- /* Switch to the per-CPU IRQ stack and call the handler */
arch/riscv/kernel/entry.S:393: load_per_cpu t0, irq_stack_ptr, t1
arch/riscv/kernel/entry.S-394- li t1, IRQ_STACK_SIZE
--
arch/riscv/kernel/entry.S-407- ret
arch/riscv/kernel/entry.S:408:SYM_FUNC_END(call_on_irq_stack)
arch/riscv/kernel/entry.S-409-#endif /* CONFIG_IRQ_STACKS */
--
arch/riscv/kernel/irq.c-15-#include <asm/smp.h>
arch/riscv/kernel/irq.c:16:#include <asm/softirq_stack.h>
arch/riscv/kernel/irq.c-17-#include <asm/stacktrace.h>
--
arch/riscv/kernel/irq.c=54=int riscv_get_hart_index(struct fwnode_handle *fwnode, u32 logical_index,
--
arch/riscv/kernel/irq.c-69-#ifdef CONFIG_IRQ_STACKS
arch/riscv/kernel/irq.c:70:#include <asm/irq_stack.h>
arch/riscv/kernel/irq.c-71-
--
arch/riscv/kernel/irq.c=78=static void init_irq_scs(void)
--
arch/riscv/kernel/irq.c-89-
arch/riscv/kernel/irq.c:90:DEFINE_PER_CPU(ulong *, irq_stack_ptr);
arch/riscv/kernel/irq.c-91-
arch/riscv/kernel/irq.c-92-#ifdef CONFIG_VMAP_STACK
arch/riscv/kernel/irq.c:93:static void init_irq_stacks(void)
arch/riscv/kernel/irq.c-94-{
--
arch/riscv/kernel/irq.c-99- p = arch_alloc_vmap_stack(IRQ_STACK_SIZE, cpu_to_node(cpu));
arch/riscv/kernel/irq.c:100: per_cpu(irq_stack_ptr, cpu) = p;
arch/riscv/kernel/irq.c-101- }
--
arch/riscv/kernel/irq.c-104-/* irq stack only needs to be 16 byte aligned - not IRQ_STACK_SIZE aligned. */
arch/riscv/kernel/irq.c:105:DEFINE_PER_CPU_ALIGNED(ulong [IRQ_STACK_SIZE/sizeof(ulong)], irq_stack);
arch/riscv/kernel/irq.c-106-
arch/riscv/kernel/irq.c:107:static void init_irq_stacks(void)
arch/riscv/kernel/irq.c-108-{
--
arch/riscv/kernel/irq.c-111- for_each_possible_cpu(cpu)
arch/riscv/kernel/irq.c:112: per_cpu(irq_stack_ptr, cpu) = per_cpu(irq_stack, cpu);
arch/riscv/kernel/irq.c-113-}
--
arch/riscv/kernel/irq.c=122=void do_softirq_own_stack(void)
--
arch/riscv/kernel/irq.c-124- if (on_thread_stack())
arch/riscv/kernel/irq.c:125: call_on_irq_stack(NULL, ___do_softirq);
arch/riscv/kernel/irq.c-126- else
--
arch/riscv/kernel/irq.c=132=static void init_irq_scs(void) {}
arch/riscv/kernel/irq.c:133:static void init_irq_stacks(void) {}
arch/riscv/kernel/irq.c-134-#endif /* CONFIG_IRQ_STACKS */
--
arch/riscv/kernel/irq.c=142=void __init init_IRQ(void)
--
arch/riscv/kernel/irq.c-144- init_irq_scs();
arch/riscv/kernel/irq.c:145: init_irq_stacks();
arch/riscv/kernel/irq.c-146- irqchip_init();
--
arch/riscv/kernel/traps.c-34-#include <asm/vector.h>
arch/riscv/kernel/traps.c:35:#include <asm/irq_stack.h>
arch/riscv/kernel/traps.c-36-
--
arch/riscv/kernel/traps.c=449=asmlinkage void noinstr do_irq(struct pt_regs *regs)
--
arch/riscv/kernel/traps.c-453- if (IS_ENABLED(CONFIG_IRQ_STACKS) && on_thread_stack())
arch/riscv/kernel/traps.c:454: call_on_irq_stack(regs, handle_riscv_irq);
arch/riscv/kernel/traps.c-455- else
--
arch/s390/kernel/dumpstack.c=55=static bool in_task_stack(unsigned long sp, struct task_struct *task,
--
arch/s390/kernel/dumpstack.c-62-
arch/s390/kernel/dumpstack.c:63:static bool in_irq_stack(unsigned long sp, struct stack_info *info)
arch/s390/kernel/dumpstack.c-64-{
--
arch/s390/kernel/dumpstack.c=91=int get_stack_info(unsigned long sp, struct task_struct *task,
--
arch/s390/kernel/dumpstack.c-108- /* Check per-cpu stacks */
arch/s390/kernel/dumpstack.c:109: if (!in_irq_stack(sp, info) &&
arch/s390/kernel/dumpstack.c-110- !in_nodat_stack(sp, info) &&
--
arch/s390/kernel/irq.c-32-#include <asm/stacktrace.h>
arch/s390/kernel/irq.c:33:#include <asm/softirq_stack.h>
arch/s390/kernel/irq.c-34-#include <asm/vtime.h>
--
arch/sh/kernel/irq.c-22-#include <cpu/mmu_context.h>
arch/sh/kernel/irq.c:23:#include <asm/softirq_stack.h>
arch/sh/kernel/irq.c-24-
--
arch/sh/kernel/irq.c=67=static union irq_ctx *softirq_ctx[NR_CPUS] __read_mostly;
arch/sh/kernel/irq.c-68-
arch/sh/kernel/irq.c:69:static char softirq_stack[NR_CPUS * THREAD_SIZE] __page_aligned_bss;
arch/sh/kernel/irq.c:70:static char hardirq_stack[NR_CPUS * THREAD_SIZE] __page_aligned_bss;
arch/sh/kernel/irq.c-71-
--
arch/sh/kernel/irq.c=120=void irq_ctx_init(int cpu)
--
arch/sh/kernel/irq.c-126-
arch/sh/kernel/irq.c:127: irqctx = (union irq_ctx *)&hardirq_stack[cpu * THREAD_SIZE];
arch/sh/kernel/irq.c-128- irqctx->tinfo.task = NULL;
--
arch/sh/kernel/irq.c-134-
arch/sh/kernel/irq.c:135: irqctx = (union irq_ctx *)&softirq_stack[cpu * THREAD_SIZE];
arch/sh/kernel/irq.c-136- irqctx->tinfo.task = NULL;
--
arch/sparc/include/asm/irq_64.h=89=void arch_trigger_cpumask_backtrace(const struct cpumask *mask,
--
arch/sparc/include/asm/irq_64.h-92-
arch/sparc/include/asm/irq_64.h:93:extern void *hardirq_stack[NR_CPUS];
arch/sparc/include/asm/irq_64.h:94:extern void *softirq_stack[NR_CPUS];
arch/sparc/include/asm/irq_64.h-95-
]
]
|
| 50/2 |
2026/05/15 18:19 |
llm |
expert |
0m
Model:
Tokens:
input: 60662
output: 35
thoughts: 1051
Thoughts: **Analyzing a Softlockup on ARM**
Okay, let's break this down. First, `arch/arm/kernel/irq.c` has `init_irq_stacks()`. Right, and it's conditional on `CONFIG_IRQSTACKS`. If that's enabled, ARM uses a separate IRQ stack. Otherwise, interrupts use the task stack, which is a potential issue. If the watchdog timer were to fire in an interrupt routine while using the task stack and the task stack is already full it could overflow.
Now, `swapper/0` is the idle thread, and its stack is `init_stack`, which is `THREAD_SIZE` large. Hmm, why would the idle thread stack be full? The idle thread just calls `do_idle` -> `schedule_idle` -> `__schedule`.
Aha, a softlockup occurred! This means the CPU was stuck. The trace says it panicked from `schedule_debug` which itself called `__schedule`. So, the CPU was likely stuck inside `__schedule`. Could it be spinning on a lock? `rq_lock(rq, &rf)` is a spinlock, if that's the culprit, it would be in `__schedule`. And, if it was spinning with interrupts disabled, the softlockup watchdog would trigger. But, wait, the watchdog is a timer interrupt. If interrupts are disabled, the timer can't fire!
Does ARM have a true NMI for the watchdog? No, except for FIQ, which is rarely used for the watchdog. So, if the watchdog fired, interrupts *must* have been enabled. But `__schedule` *disables* interrupts: `local_irq_disable()`. How could the watchdog trigger if interrupts are disabled?
Ah, the "Tainted: [L]=SOFTLOCKUP" message. It doesn't mean the softlockup is happening *right now*, but a *previous* softlockup occurred, and the kernel is tainted. Okay, so the system was running, a softlockup happened, it recovered, and *then* it panicked later. The uptime isn't shown, but "Rebooting in 86400 seconds..." gives me a hint.
So if a softlockup previously happened, maybe the stack was corrupted during that initial softlockup? If the stack *was* corrupted, then `schedule_debug` would have caught it the next time `__schedule` was called. When does `__schedule` get called? The `swapper/0` thread calls `__schedule` when it goes idle or wakes up.
If the stack was corrupted, what corrupted it? The trace again... It shows `show_stack` being called. And, wait... there it is! `[<80202800>] (panic) from [<8021e458>] (dump_stack_lvl+0x5c/0x70 lib/dump_stack.c:120)` followed by a chain that leads to... `trace_suspend_resume+0x0/0x104 kernel/panic.c:787`? Yes, that's `panic()`, just a slight offset. Let me check `kernel/panic.c`...
|
| 51/2 |
2026/05/15 18:19 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/panic.c IncludeLines:true Name:panic]
Results: map[SourceCode: 781: /* Identical to vpanic(), except it takes variadic arguments instead of va_list */
782: void panic(const char *fmt, ...)
783: {
784: va_list args;
785:
786: va_start(args, fmt);
787: vpanic(fmt, args);
788: va_end(args);
789: }
SourceFile:kernel/panic.c]
|
| 52/2 |
2026/05/15 18:19 |
llm |
expert |
0m
Model:
Tokens:
input: 62598
output: 20
thoughts: 1020
Thoughts: **Analyzing a Kernel Stack Corruption Panic**
Okay, so `panic` calls `vpanic`, confirming the trace is correct. The immediate question is why `task_stack_end_corrupted(prev)` returned true. It's because `*(end_of_stack(prev))`, which is `init_stack[0]`, doesn't equal `STACK_END_MAGIC`. `prev` is `swapper/0`, and `end_of_stack(prev)` points to `init_stack`. Therefore, `init_stack[0]` has been overwritten.
What could possibly overwrite `init_stack[0]`? Let's consider the possibilities: a stack overflow of `swapper/0`, an out-of-bounds write from elsewhere, or a use-after-free, though the last is unlikely given that `init_stack` is a static variable.
Could it be a stack overflow? If `swapper/0` overflowed its stack, it would definitely overwrite `init_stack[0]`. What exactly runs on `swapper/0`'s stack? Interrupts! Unless `CONFIG_IRQSTACKS` is enabled, interrupts run on the task stack. If there's a storm of interrupts, or deeply nested interrupts, this could cause an overflow. And wait, `syzkaller` is running... it's known to be capable of triggering a lot of things.
`swapper/0` is the idle thread, running on CPU 0. If `syzkaller` somehow triggered an infinite recursion in an interrupt handler, that *could* overflow the stack. But, an infinite recursion would likely crash in the interrupt handler, not in `__schedule` unless it stopped just after the overwrite. Hang on – `STACK_END_MAGIC` is at the very *bottom* of the stack. If the stack grows down, it would hit `init_stack[0]` if it's overflowing. If an interrupt handler uses a lot of stack space, that could cause the corruption.
Is there any known ARM Versatile Express bug with a stack overflow? Or perhaps it's a generic issue? The bug report states "Kernel panic - not syncing: corrupted stack end detected inside scheduler". This is a generic symptom of a stack overflow or out-of-bounds write. Since `syzkaller` is involved, it could be highlighting a specific bug. The report doesn't contain a reproducer or any other crash logs, just this panic.
How do I assess the security impact? If an unprivileged user can trigger a stack overflow, that's definitely a vulnerability. Can this be triggered by an unprivileged user? Usually, yes, if there's an issue like unbounded recursion or a large stack allocation in a syscall. But, the panic occurred in `swapper/0`, which means the stack overflow happened when the CPU was idle or handling an interrupt during the idle state.
If the corruption happened during an interrupt, it could be a network packet processing (softirq) that exhausted the stack. Or, it could be an out-of-bounds write from a completely unrelated process that just happened to corrupt `init_stack`. Wait, `init_stack` is located in the `.data` section. Let me check the exact location of `init_stack` again – it’s in something like `.data..init_task`. A global out-of-bounds write could hit it. However, the `swapper/0` stack overflow remains the most likely cause because `init_stack` *is* `swapper/0`'s stack.
If `swapper/0`'s stack overflowed, why? Most likely because of deeply nested interrupts or softirqs. Now, is this exploitable? A kernel stack overflow is generally considered exploitable, often by overwriting `thread_info` or other critical data, potentially leading to privilege escalation or code execution. But, wait, on ARM, `thread_info` is at the bottom of the stack! Let me double-check `end_of_stack` on ARM. If `CONFIG_THREAD_INFO_IN_TASK` is enabled, `thread_info` is in `task_struct`, not on the stack. The `arch/arm/Kconfig` selects `THREAD_INFO_IN_TASK`. So `thread_info` is *not* on the stack. However, `STACK_END_MAGIC` *is* at the bottom of the stack. If the stack overflows, it overwrites `STACK_END_MAGIC`, and whatever memory lies below. What is below `init_stack` in memory? I need to check `vmlinux.lds.h` for `init_stack` to determine what adjacent data may be vulnerable.
|
| 53/2 |
2026/05/15 18:20 |
tool |
grepper |
0m
Args: map[Expression:__start_init_stack]
Results: map[Output:include/asm-generic/vmlinux.lds.h-426- . = ALIGN(align); \
include/asm-generic/vmlinux.lds.h:427: __start_init_stack = .; \
include/asm-generic/vmlinux.lds.h-428- init_thread_union = .; \
--
include/asm-generic/vmlinux.lds.h-430- KEEP(*(.data..init_thread_info)) \
include/asm-generic/vmlinux.lds.h:431: . = __start_init_stack + THREAD_SIZE; \
include/asm-generic/vmlinux.lds.h-432- __end_init_stack = .;
]
|
| 54/2 |
2026/05/15 18:20 |
llm |
expert |
0m
Model:
Tokens:
input: 64842
output: 19
thoughts: 15
Thoughts: Here's a summary of my thoughts, assuming I'm already well-versed in kernel internals:
**Digging into INIT_TASK_DATA and init_stack**
Okay, so I'm thinking about `INIT_TASK_DATA`. It's pretty fundamental, right? That's where a lot of the initial setup for the first process, the "init" process, is stored. And within `INIT_TASK_DATA`, I'm specifically focused on `init_stack`. It makes perfect sense that the initial stack for this crucial first task would reside in there. No surprises so far, but it's always good to refresh the fundamentals. I'm wondering if there are any subtle optimization opportunities linked to its size or placement...something to explore later, maybe.
|
| 55/2 |
2026/05/15 18:20 |
tool |
grepper |
0m
Args: map[Expression:INIT_TASK_DATA]
Results: map[Output:arch/mips/kernel/vmlinux.lds.S=43=SECTIONS
--
arch/mips/kernel/vmlinux.lds.S-93-
arch/mips/kernel/vmlinux.lds.S:94: INIT_TASK_DATA(THREAD_SIZE)
arch/mips/kernel/vmlinux.lds.S-95- NOSAVE_DATA
--
arch/powerpc/kernel/vmlinux.lds.S=48=SECTIONS
--
arch/powerpc/kernel/vmlinux.lds.S-365- /* The initial task and kernel stack */
arch/powerpc/kernel/vmlinux.lds.S:366: INIT_TASK_DATA_SECTION(THREAD_ALIGN)
arch/powerpc/kernel/vmlinux.lds.S-367-
--
arch/um/kernel/dyn.lds.S=15=SECTIONS
--
arch/um/kernel/dyn.lds.S-117- .data : {
arch/um/kernel/dyn.lds.S:118: INIT_TASK_DATA(KERNEL_STACK_SIZE)
arch/um/kernel/dyn.lds.S-119- DATA_DATA
--
arch/um/kernel/uml.lds.S=16=SECTIONS
--
arch/um/kernel/uml.lds.S-78- {
arch/um/kernel/uml.lds.S:79: INIT_TASK_DATA(KERNEL_STACK_SIZE)
arch/um/kernel/uml.lds.S-80- DATA_DATA
--
arch/x86/kernel/vmlinux.lds.S=124=SECTIONS
--
arch/x86/kernel/vmlinux.lds.S-179- /* init_task */
arch/x86/kernel/vmlinux.lds.S:180: INIT_TASK_DATA(THREAD_SIZE)
arch/x86/kernel/vmlinux.lds.S-181-
--
include/asm-generic/vmlinux.lds.h-424-
include/asm-generic/vmlinux.lds.h:425:#define INIT_TASK_DATA(align) \
include/asm-generic/vmlinux.lds.h-426- . = ALIGN(align); \
--
include/asm-generic/vmlinux.lds.h-701- */
include/asm-generic/vmlinux.lds.h:702:#define INIT_TASK_DATA_SECTION(align) \
include/asm-generic/vmlinux.lds.h-703- . = ALIGN(align); \
include/asm-generic/vmlinux.lds.h-704- .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) { \
include/asm-generic/vmlinux.lds.h:705: INIT_TASK_DATA(align) \
include/asm-generic/vmlinux.lds.h-706- }
--
include/asm-generic/vmlinux.lds.h-1140- .data : AT(ADDR(.data) - LOAD_OFFSET) { \
include/asm-generic/vmlinux.lds.h:1141: INIT_TASK_DATA(inittask) \
include/asm-generic/vmlinux.lds.h-1142- NOSAVE_DATA \
]
|
| 56/2 |
2026/05/15 18:20 |
llm |
expert |
0m
Model:
Tokens:
input: 65907
output: 19
thoughts: 19
Thoughts: Here's a summary of my thought process, as requested:
**Diving into the Linker Script**
Alright, time to dig into the heart of the beast. I need to get a handle on how this ARM kernel image is structured, so let's start with the linker script. My first instinct is to examine `arch/arm/kernel/vmlinux.lds.S`. This file is crucial; it's the recipe that guides the linker in creating the `vmlinux` kernel image. It dictates the memory layout, section placement, and symbol definitions, all the essential ingredients for a runnable kernel. I want to see how memory regions are defined and if the specific features I am working with are included. I will be looking for common things like text, data, bss sections, and any custom segments specific to this ARM architecture or kernel configuration. From here, I can get a better sense of the overall memory map and where my specific area of interest, or possible conflicts might lie.
|
| 57/2 |
2026/05/15 18:20 |
tool |
grepper |
0m
Args: map[Expression:INIT_TASK_DATA]
Results: map[Output:arch/mips/kernel/vmlinux.lds.S=43=SECTIONS
--
arch/mips/kernel/vmlinux.lds.S-93-
arch/mips/kernel/vmlinux.lds.S:94: INIT_TASK_DATA(THREAD_SIZE)
arch/mips/kernel/vmlinux.lds.S-95- NOSAVE_DATA
--
arch/powerpc/kernel/vmlinux.lds.S=48=SECTIONS
--
arch/powerpc/kernel/vmlinux.lds.S-365- /* The initial task and kernel stack */
arch/powerpc/kernel/vmlinux.lds.S:366: INIT_TASK_DATA_SECTION(THREAD_ALIGN)
arch/powerpc/kernel/vmlinux.lds.S-367-
--
arch/um/kernel/dyn.lds.S=15=SECTIONS
--
arch/um/kernel/dyn.lds.S-117- .data : {
arch/um/kernel/dyn.lds.S:118: INIT_TASK_DATA(KERNEL_STACK_SIZE)
arch/um/kernel/dyn.lds.S-119- DATA_DATA
--
arch/um/kernel/uml.lds.S=16=SECTIONS
--
arch/um/kernel/uml.lds.S-78- {
arch/um/kernel/uml.lds.S:79: INIT_TASK_DATA(KERNEL_STACK_SIZE)
arch/um/kernel/uml.lds.S-80- DATA_DATA
--
arch/x86/kernel/vmlinux.lds.S=124=SECTIONS
--
arch/x86/kernel/vmlinux.lds.S-179- /* init_task */
arch/x86/kernel/vmlinux.lds.S:180: INIT_TASK_DATA(THREAD_SIZE)
arch/x86/kernel/vmlinux.lds.S-181-
--
include/asm-generic/vmlinux.lds.h-424-
include/asm-generic/vmlinux.lds.h:425:#define INIT_TASK_DATA(align) \
include/asm-generic/vmlinux.lds.h-426- . = ALIGN(align); \
--
include/asm-generic/vmlinux.lds.h-701- */
include/asm-generic/vmlinux.lds.h:702:#define INIT_TASK_DATA_SECTION(align) \
include/asm-generic/vmlinux.lds.h-703- . = ALIGN(align); \
include/asm-generic/vmlinux.lds.h-704- .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) { \
include/asm-generic/vmlinux.lds.h:705: INIT_TASK_DATA(align) \
include/asm-generic/vmlinux.lds.h-706- }
--
include/asm-generic/vmlinux.lds.h-1140- .data : AT(ADDR(.data) - LOAD_OFFSET) { \
include/asm-generic/vmlinux.lds.h:1141: INIT_TASK_DATA(inittask) \
include/asm-generic/vmlinux.lds.h-1142- NOSAVE_DATA \
]
|
| 58/2 |
2026/05/15 18:20 |
llm |
expert |
0m
Model:
Tokens:
input: 67020
output: 17
thoughts: 1911
Thoughts: **Analyzing a Kernel Panic: A Stack Overflow in the Idle Thread**
Okay, let's break this down. We've got a kernel panic, and the clue is that `init_stack[0]` contains the address `init_stack + 0x1c`. That screams stack overflow. I'm seeing this value in the ARM architecture code specifically.
First, I need to understand the memory layout. The code uses `RW_DATA` in `vmlinux.lds.S`, which includes `INIT_TASK_DATA`. Let's clarify what this means. I know that `INIT_TASK_DATA` is for the initial thread's data, and it's placed in the `.data` section. If `INIT_TASK_DATA` is at the *beginning* of `.data`, then what comes before `.data`? Usually `.rodata` or `.text` or `__init_begin`, which are read-only or executable. An out-of-bounds write *from* those is impossible, or highly unlikely. So, the overflow must be coming from elsewhere.
The fact that `init_stack` is `THREAD_SIZE` aligned and that the offending address is `init_stack + 0x1c` is crucial. This is typical of a function saving a frame pointer (FP) or stack pointer (SP) on the stack. The assembly looks like it's trying to validate the stack with a magic value `STACK_END_MAGIC`. It's reading the value from the `end_of_stack` address and comparing it. The fact that `end_of_stack` contains a seemingly valid address is not good.
It reads that `init_stack[0]` is storing `init_stack + 0x1c`! Why would `init_stack[0]` be overwritten with an address on the stack? That's a classic symptom. A function was called that pushed the frame pointer or stack pointer, which happened to be `init_stack + 0x1c`. This overwrites `init_stack[0]`! If the stack pointer overflows, then `dump_stack` is called.
Okay, so what caused the stack overflow in the *idle thread* (`swapper/0`)? The idle thread handles interrupts. So, something in an interrupt handler could be the cause. An interrupt storm or deeply nested interrupts are possible. The "Tainted: [L]=SOFTLOCKUP" message is interesting. A softlockup means the CPU was stuck. Was it stuck in an interrupt handler, a softirq, or a recursive loop? A network driver, or a timer? The page fault in an interrupt handler could cause a double fault. But it's almost certainly the watchdog. If a softlockup occurs, the watchdog fires and calls `dump_stack`.
And if the stack was already close to full, `dump_stack` *itself* could overflow the stack! It would push a lot of stuff. The watchdog fires after a delay, so the CPU was stuck for some time. Then, the watchdog's timer interrupt fires, and a handler is called. On ARM, the softlockup watchdog uses a normal timer interrupt. Interrupts must be *enabled* for the watchdog to trigger. If they were enabled, the CPU got stuck in a loop. Then, the watchdog fires.
The watchdog calls a function (similar to `softlockup_fn`) which then calls `dump_stack`. `dump_stack` overflows the stack! Then, `dump_stack` returns, and the CPU goes back to the loop. How does this reach `__schedule`? Maybe the loop was in a task that was *preempted*? If `swapper/0` was stuck in the loop with interrupts enabled, it could be preempted if `NEED_RESCHED` is set. Or the loop was in `do_idle`? `do_idle` calls `cpuidle_enter`, which might enable interrupts. Could there be a known bug in the ARM Versatile Express cpuidle driver? Or did `syzkaller` trigger a bug that corrupted the stack?
Okay, so now let's think about this a bit more. The address `8280001c` is `init_stack + 0x1c`. If `syzkaller` causes the out-of-bounds write, it could write the address directly. But writing the *precise address* of the stack pointer into the stack is very characteristic of a stack overflow. We're talking about writing to `init_stack[0]`, which contains an address on the stack: it's almost certainly a stack overflow.
Is this exploitable? Yes, stack overflows can overwrite crucial parts of the kernel, like `thread_info` (which is stored on
|
| 59/2 |
2026/05/15 18:21 |
tool |
grepper |
0m
Args:
Results: map[Output:arch/alpha/boot/bootloader.lds=5=SECTIONS
--
arch/alpha/boot/bootloader.lds-11- .rodata : { *(.rodata) *(.rodata.*) }
arch/alpha/boot/bootloader.lds:12: .data : { *(.data) CONSTRUCTORS }
arch/alpha/boot/bootloader.lds-13- .got : { *(.got) }
--
arch/arc/kernel/vmlinux.lds.S=20=SECTIONS
--
arch/arc/kernel/vmlinux.lds.S-64- /* INIT_DATA_SECTION open-coded: special INIT_RAM_FS handling */
arch/arc/kernel/vmlinux.lds.S:65: .init.data : {
arch/arc/kernel/vmlinux.lds.S-66- INIT_DATA
--
arch/arm/boot/compressed/vmlinux.lds.S=18=SECTIONS
--
arch/arm/boot/compressed/vmlinux.lds.S-82-#ifdef CONFIG_EFI_STUB
arch/arm/boot/compressed/vmlinux.lds.S:83: .data : ALIGN(4096) {
arch/arm/boot/compressed/vmlinux.lds.S-84- __pecoff_data_start = .;
--
arch/arm/kernel/vmlinux-xip.lds.S=27=SECTIONS
--
arch/arm/kernel/vmlinux-xip.lds.S-123- __init_begin = .;
arch/arm/kernel/vmlinux-xip.lds.S:124: .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
arch/arm/kernel/vmlinux-xip.lds.S-125- INIT_DATA
arch/arm/kernel/vmlinux-xip.lds.S-126- }
arch/arm/kernel/vmlinux-xip.lds.S:127: .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
arch/arm/kernel/vmlinux-xip.lds.S-128- ARM_EXIT_KEEP(EXIT_DATA)
--
arch/arm/kernel/vmlinux.lds.S=27=SECTIONS
--
arch/arm/kernel/vmlinux.lds.S-124-
arch/arm/kernel/vmlinux.lds.S:125: .exit.data : {
arch/arm/kernel/vmlinux.lds.S-126- ARM_EXIT_KEEP(EXIT_DATA)
--
arch/arm64/kernel/vmlinux.lds.S=163=SECTIONS
--
arch/arm64/kernel/vmlinux.lds.S-265-
arch/arm64/kernel/vmlinux.lds.S:266: .init.data : {
arch/arm64/kernel/vmlinux.lds.S-267- INIT_DATA
--
arch/arm64/kernel/vmlinux.lds.S-273- }
arch/arm64/kernel/vmlinux.lds.S:274: .exit.data : {
arch/arm64/kernel/vmlinux.lds.S-275- EXIT_DATA
--
arch/loongarch/kernel/vmlinux.lds.S=36=SECTIONS
--
arch/loongarch/kernel/vmlinux.lds.S-84- INIT_DATA_SECTION(16)
arch/loongarch/kernel/vmlinux.lds.S:85: .exit.data : {
arch/loongarch/kernel/vmlinux.lds.S-86- EXIT_DATA
--
arch/m68k/kernel/vmlinux-nommu.lds=29=SECTIONS {
--
arch/m68k/kernel/vmlinux-nommu.lds-77- }
arch/m68k/kernel/vmlinux-nommu.lds:78: .init.data : {
arch/m68k/kernel/vmlinux-nommu.lds-79- . = ALIGN(PAGE_SIZE);
--
arch/microblaze/kernel/vmlinux.lds.S=27=SECTIONS {
--
arch/microblaze/kernel/vmlinux.lds.S-98-
arch/microblaze/kernel/vmlinux.lds.S:99: .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
arch/microblaze/kernel/vmlinux.lds.S-100- INIT_DATA
--
arch/mips/boot/compressed/ld.script=14=SECTIONS
--
arch/mips/boot/compressed/ld.script-24- /* Writable data */
arch/mips/boot/compressed/ld.script:25: .data : {
arch/mips/boot/compressed/ld.script-26- *(.data)
--
arch/mips/kernel/vmlinux.lds.S=43=SECTIONS
--
arch/mips/kernel/vmlinux.lds.S-90- /* writeable */
arch/mips/kernel/vmlinux.lds.S:91: .data : { /* Data */
arch/mips/kernel/vmlinux.lds.S-92- . = . + DATAOFFSET; /* for CONFIG_MAPPED_KERNEL */
--
arch/mips/kernel/vmlinux.lds.S-136- }
arch/mips/kernel/vmlinux.lds.S:137: .exit.data : {
arch/mips/kernel/vmlinux.lds.S-138- EXIT_DATA
--
arch/nios2/boot/compressed/vmlinux.lds.S=13=SECTIONS
--
arch/nios2/boot/compressed/vmlinux.lds.S-23- . = ALIGN(32 / 8);
arch/nios2/boot/compressed/vmlinux.lds.S:24: .data : { *(.data) }
arch/nios2/boot/compressed/vmlinux.lds.S-25- . = ALIGN(32 / 8);
--
arch/nios2/boot/compressed/vmlinux.scr=19=SECTIONS
arch/nios2/boot/compressed/vmlinux.scr-20-{
arch/nios2/boot/compressed/vmlinux.scr:21: .data : {
arch/nios2/boot/compressed/vmlinux.scr-22- input_len = .;
--
arch/parisc/boot/compressed/vmlinux.lds.S=15=SECTIONS
--
arch/parisc/boot/compressed/vmlinux.lds.S-62- . = ALIGN(8);
arch/parisc/boot/compressed/vmlinux.lds.S:63: .data : {
arch/parisc/boot/compressed/vmlinux.lds.S-64- _data = . ;
--
arch/parisc/kernel/vmlinux.lds.S=56=SECTIONS
--
arch/parisc/kernel/vmlinux.lds.S-66- MLONGCALL_DISCARD(EXIT_TEXT_SECTIONS())
arch/parisc/kernel/vmlinux.lds.S:67: .exit.data :
arch/parisc/kernel/vmlinux.lds.S-68- {
--
arch/parisc/mm/init.c=531=void __init mem_init(void)
--
arch/parisc/mm/init.c-583- " .init : 0x%px - 0x%px (%4ld kB)\n"
arch/parisc/mm/init.c:584: " .data : 0x%px - 0x%px (%4ld kB)\n"
arch/parisc/mm/init.c-585- " .text : 0x%px - 0x%px (%4ld kB)\n",
--
arch/powerpc/kernel/vmlinux.lds.S=48=SECTIONS
--
arch/powerpc/kernel/vmlinux.lds.S-341- */
arch/powerpc/kernel/vmlinux.lds.S:342: .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
arch/powerpc/kernel/vmlinux.lds.S-343- EXIT_DATA
--
arch/powerpc/kernel/vmlinux.lds.S-356-
arch/powerpc/kernel/vmlinux.lds.S:357: .data : AT(ADDR(.data) - LOAD_OFFSET) {
arch/powerpc/kernel/vmlinux.lds.S-358- DATA_DATA
--
arch/riscv/kernel/vmlinux-xip.lds.S=24=SECTIONS
--
arch/riscv/kernel/vmlinux-xip.lds.S-85- __init_begin = .;
arch/riscv/kernel/vmlinux-xip.lds.S:86: .init.data : {
arch/riscv/kernel/vmlinux-xip.lds.S-87- INIT_DATA
arch/riscv/kernel/vmlinux-xip.lds.S-88- }
arch/riscv/kernel/vmlinux-xip.lds.S:89: .exit.data : {
arch/riscv/kernel/vmlinux-xip.lds.S-90- EXIT_DATA
--
arch/riscv/kernel/vmlinux.lds.S=30=SECTIONS
--
arch/riscv/kernel/vmlinux.lds.S-95- }
arch/riscv/kernel/vmlinux.lds.S:96: .exit.data :
arch/riscv/kernel/vmlinux.lds.S-97- {
--
arch/s390/boot/vmlinux.lds.S=14=SECTIONS
--
arch/s390/boot/vmlinux.lds.S-47- NOTES
arch/s390/boot/vmlinux.lds.S:48: .data : {
arch/s390/boot/vmlinux.lds.S-49- _data = . ;
--
arch/s390/include/asm/vmlinux.lds.h-15- . = ALIGN(PAGE_SIZE); \
arch/s390/include/asm/vmlinux.lds.h:16: .boot.data : { \
arch/s390/include/asm/vmlinux.lds.h-17- __boot_data_start = .; \
--
arch/s390/include/asm/vmlinux.lds.h-28- . = ALIGN(PAGE_SIZE); \
arch/s390/include/asm/vmlinux.lds.h:29: .boot.preserved.data : { \
arch/s390/include/asm/vmlinux.lds.h-30- __boot_data_preserved_start = .; \
--
arch/s390/kernel/vmlinux.lds.S=40=SECTIONS
--
arch/s390/kernel/vmlinux.lds.S-125-
arch/s390/kernel/vmlinux.lds.S:126: .exit.data : {
arch/s390/kernel/vmlinux.lds.S-127- EXIT_DATA
--
arch/s390/kernel/vmlinux.lds.S-198- . = ALIGN(PAGE_SIZE);
arch/s390/kernel/vmlinux.lds.S:199: .amode31.data : {
arch/s390/kernel/vmlinux.lds.S-200- *(.amode31.data)
--
arch/s390/purgatory/purgatory.lds.S=10=SECTIONS
--
arch/s390/purgatory/purgatory.lds.S-29- }
arch/s390/purgatory/purgatory.lds.S:30: .data : {
arch/s390/purgatory/purgatory.lds.S-31- _data = . ;
--
arch/sh/kernel/vmlinux.lds.S=19=SECTIONS
--
arch/sh/kernel/vmlinux.lds.S-69- .exit.text : AT(ADDR(.exit.text)) { EXIT_TEXT }
arch/sh/kernel/vmlinux.lds.S:70: .exit.data : AT(ADDR(.exit.data)) { EXIT_DATA }
arch/sh/kernel/vmlinux.lds.S-71-
--
arch/sh/mm/init.c=329=void __init mem_init(void)
--
arch/sh/mm/init.c-347- " .init : 0x%08lx - 0x%08lx (%4ld kB)\n"
arch/sh/mm/init.c:348: " .data : 0x%08lx - 0x%08lx (%4ld kB)\n"
arch/sh/mm/init.c-349- " .text : 0x%08lx - 0x%08lx (%4ld kB)\n",
--
arch/sparc/kernel/vmlinux.lds.S=41=SECTIONS
--
arch/sparc/kernel/vmlinux.lds.S-182-
arch/sparc/kernel/vmlinux.lds.S:183: .exit.data : {
arch/sparc/kernel/vmlinux.lds.S-184- EXIT_DATA
--
arch/um/include/asm/common.lds.S-76- .exit.text : { EXIT_TEXT }
arch/um/include/asm/common.lds.S:77: .exit.data : { *(.exit.data) }
arch/um/include/asm/common.lds.S-78-
--
arch/um/kernel/dyn.lds.S=15=SECTIONS
--
arch/um/kernel/dyn.lds.S-101- __init_begin = .;
arch/um/kernel/dyn.lds.S:102: init.data : { INIT_DATA }
arch/um/kernel/dyn.lds.S-103- __init_end = .;
--
arch/um/kernel/uml.lds.S=16=SECTIONS
--
arch/um/kernel/uml.lds.S-73- __init_begin = .;
arch/um/kernel/uml.lds.S:74: init.data : { INIT_DATA }
arch/um/kernel/uml.lds.S-75- __init_end = .;
--
arch/x86/boot/compressed/vmlinux.lds.S=19=SECTIONS
--
arch/x86/boot/compressed/vmlinux.lds.S-53-#endif
arch/x86/boot/compressed/vmlinux.lds.S:54: .data : ALIGN(0x1000) {
arch/x86/boot/compressed/vmlinux.lds.S-55- _data = . ;
--
arch/x86/kernel/vmlinux.lds.S=124=SECTIONS
--
arch/x86/kernel/vmlinux.lds.S-174- /* Data */
arch/x86/kernel/vmlinux.lds.S:175: .data : AT(ADDR(.data) - LOAD_OFFSET) {
arch/x86/kernel/vmlinux.lds.S-176- /* Start of data section */
--
arch/x86/kernel/vmlinux.lds.S-331-
arch/x86/kernel/vmlinux.lds.S:332: .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
arch/x86/kernel/vmlinux.lds.S-333- EXIT_DATA
--
arch/x86/realmode/rm/realmode.lds.S=16=SECTIONS
--
arch/x86/realmode/rm/realmode.lds.S-54- . = ALIGN(PAGE_SIZE);
arch/x86/realmode/rm/realmode.lds.S:55: .data : {
arch/x86/realmode/rm/realmode.lds.S-56- *(.data)
--
arch/xtensa/kernel/vmlinux.lds.S=80=SECTIONS
--
arch/xtensa/kernel/vmlinux.lds.S-153-
arch/xtensa/kernel/vmlinux.lds.S:154: .init.data :
arch/xtensa/kernel/vmlinux.lds.S-155- {
--
arch/xtensa/kernel/vmlinux.lds.S-366- __init_begin = .;
arch/xtensa/kernel/vmlinux.lds.S:367: .init.data :
arch/xtensa/kernel/vmlinux.lds.S-368- {
--
drivers/firmware/efi/libstub/zboot.lds=7=SECTIONS
--
drivers/firmware/efi/libstub/zboot.lds-38-
drivers/firmware/efi/libstub/zboot.lds:39: .data : ALIGN(4096) {
drivers/firmware/efi/libstub/zboot.lds-40- _data = .;
--
drivers/i3c/master/svc-i3c-master.c=1668=static int svc_i3c_master_send_direct_ccc_cmd(struct svc_i3c_master *master,
--
drivers/i3c/master/svc-i3c-master.c-1696- cmd->rnw = ccc->rnw;
drivers/i3c/master/svc-i3c-master.c:1697: cmd->in = ccc->rnw ? ccc->dests[0].payload.data : NULL;
drivers/i3c/master/svc-i3c-master.c-1698- cmd->out = ccc->rnw ? NULL : ccc->dests[0].payload.data;
--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h=177=static inline void *lookup_atid(const struct tid_info *t, unsigned int atid)
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h-178-{
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h:179: return atid < t->natids ? t->atid_tab[atid].data : NULL;
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h-180-}
--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h=182=static inline void *lookup_stid(const struct tid_info *t, unsigned int stid)
--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h-191-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h:192: return stid < (t->nstids + t->nsftids) ? t->stid_tab[stid].data : NULL;
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h-193-}
--
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c=217=iwl_parse_nvm_sections(struct iwl_mvm *mvm)
--
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c-270- regulatory = mvm->trans->cfg->nvm_type == IWL_NVM_SDP ?
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c:271: (const __le16 *)sections[NVM_SECTION_TYPE_REGULATORY_SDP].data :
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c-272- (const __le16 *)sections[NVM_SECTION_TYPE_REGULATORY].data;
--
drivers/pci/vc.c=185=static int pci_vc_do_save_buffer(struct pci_dev *dev, int pos,
--
drivers/pci/vc.c-191- int i, len = 0;
drivers/pci/vc.c:192: u8 *buf = save_state ? (u8 *)save_state->cap.data : NULL;
drivers/pci/vc.c-193-
--
include/asm-generic/vmlinux.lds.h-1139- . = ALIGN(PAGE_SIZE); \
include/asm-generic/vmlinux.lds.h:1140: .data : AT(ADDR(.data) - LOAD_OFFSET) { \
include/asm-generic/vmlinux.lds.h-1141- INIT_TASK_DATA(inittask) \
--
include/asm-generic/vmlinux.lds.h-1160-#define INIT_DATA_SECTION(initsetup_align) \
include/asm-generic/vmlinux.lds.h:1161: .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) { \
include/asm-generic/vmlinux.lds.h-1162- INIT_DATA \
--
include/rdma/uverbs_ioctl.h=781=static inline void *uverbs_attr_get_alloced_ptr(
--
include/rdma/uverbs_ioctl.h-788-
include/rdma/uverbs_ioctl.h:789: return uverbs_attr_ptr_is_inline(attr) ? (void *)&attr->ptr_attr.data :
include/rdma/uverbs_ioctl.h-790- attr->ptr_attr.ptr;
--
samples/acrn/guest.ld=3=SECTIONS
--
samples/acrn/guest.ld-7- .rodata : { *(.rodata) }
samples/acrn/guest.ld:8: .data : { *(.data) }
samples/acrn/guest.ld-9-}
--
scripts/module.lds.S=14=SECTIONS {
--
scripts/module.lds.S-52-
scripts/module.lds.S:53: .data : {
scripts/module.lds.S-54- *(.data .data.[0-9a-zA-Z_]*)
--
tools/testing/selftests/sgx/test_encl.lds=10=SECTIONS
--
tools/testing/selftests/sgx/test_encl.lds-25-
tools/testing/selftests/sgx/test_encl.lds:26: .data : {
tools/testing/selftests/sgx/test_encl.lds-27- *(.data.encl_buffer)
]
|
| 60/2 |
2026/05/15 18:21 |
llm |
expert |
0m
Model:
Tokens:
input: 75891
output: 20
thoughts: 2092
Thoughts: **Analysis of a Kernel Stack Overflow Leading to a Denial of Service**
Okay, let's break this down. First, the crash is happening in `swapper/0`, which is the idle thread. The initial clue is the stack overflow, indicated by the `.data` section layout in the linker script. `INIT_TASK_DATA` is right at the beginning of `.data`, implying that the overflow is likely on the stack, not from data corruption. A stack overflow in the kernel is a memory corruption bug, almost certainly. Syzkaller found it, so it's probably triggered by an unprivileged user.
The key is the "Tainted: G L syzkaller" flag and the CPU context, the panic in `swapper/0`, this tells a lot. The `L` taint flag, specifically, screams "softlockup." Syzkaller is likely the trigger, which means it is very accessible. The fact that the panic is in the idle thread strongly suggests a problem that happens during interrupt handling. Maybe a softirq got stuck in a loop. Or a timer interrupt, but the panic is not in the timer interrupt routine itself. So, it's very likely a softlockup being detected by the watchdog.
The sequence of events becomes clearer: the idle thread is busy, the loop happens, the watchdog timer fires, the taint flag is set, and `dump_stack` is called. The watchdog would call `dump_stack`, that's what overflows the stack. That's why the stack is corrupted in `swapper/0`.
If the watchdog had interrupted a syscall, the trace would be different. Instead, the loop in the softirq must have *terminated*, and then `__schedule` was called, and it paniced. So it's not a direct stack overflow in a syscall. It's a softlockup, which means the CPU was busy for 20 seconds, and it set the taint flag. If `dump_stack` is called due to the watchdog, then it means `dump_stack` didn't happen right after the softlockup. It happened sometime after, when things returned back to normal-ish idle. This is why the stack got overflowed!
Therefore, the root cause is a long operation – most likely an infinite loop or a very, very long loop – within an interrupt context. The overflow is *secondary* to the DoS caused by the loop, not the other way around. Since the stack corruption occurs in `dump_stack`, the attacker doesn't control the data that overwrites the stack. No privilege escalation.
This aligns with a Denial of Service, not a privilege escalation. The loop is the primary bug, the overflow is a side effect. It could be triggered by network packets, file system operations, or even VM-related triggers. It *is* accessible from an unprivileged user, and user namespaces, hence `syzkaller` caught it. It's almost certainly not easily exploitable. Since we don't know the exact trigger, we should assume a conservative approach. We can't say it's *not* remotely triggered, but the prompt advises erring on the side of non-exploitable/not-accessible. Hence: DoS, unprivileged access, not exploitable.
|
| 61/2 |
2026/05/15 18:21 |
tool |
grepper |
0m
Args: map[Expression:TAINT_SOFTLOCKUP]
Results: map[Output:drivers/dma-buf/sw_sync.c=344=static long sw_sync_ioctl_create_fence(struct sync_timeline *obj,
--
drivers/dma-buf/sw_sync.c-353- /* SW sync fence are inherently unsafe and can deadlock the kernel */
drivers/dma-buf/sw_sync.c:354: add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
drivers/dma-buf/sw_sync.c-355-
--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c=4196=static int amdgpu_device_get_job_timeout_settings(struct amdgpu_device *adev)
--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c-4222- dev_warn(adev->dev, "lockup timeout disabled");
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:4223: add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c-4224- } else {
--
include/linux/panic.h=64=static inline void set_arch_panic_timeout(int timeout, int arch_default_timeout)
--
include/linux/panic.h-84-#define TAINT_UNSIGNED_MODULE 13
include/linux/panic.h:85:#define TAINT_SOFTLOCKUP 14
include/linux/panic.h-86-#define TAINT_LIVEPATCH 15
--
kernel/watchdog.c=773=static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
--
kernel/watchdog.c-879-
kernel/watchdog.c:880: add_taint(TAINT_SOFTLOCKUP, LOCKDEP_STILL_OK);
kernel/watchdog.c-881- sys_info(softlockup_si_mask & ~SYS_INFO_ALL_BT);
]
|
| 62/2 |
2026/05/15 18:21 |
llm |
expert |
0m
Model:
Tokens:
input: 79223
output: 18
thoughts: 64
Thoughts: **Decoding Kernel Taint Flags**
Okay, so I'm looking at this `TAINT_SOFTLOCKUP` flag, and it's assigned the value 14. Hmm, that's interesting. I remember seeing a correspondence between these numerical taint flags and letters, right? Let me see... I need to find where those are defined. Ah yes, in `kernel/panic.c`. Let me quickly confirm the pattern... 'G' is 0, 'W' is 1... it's just sequential alphabetical mapping. Alright, so 14 is definitely 'L'. Now, I need to jog my memory on what each of these letters signifies in terms of the taint flags themselves. Let me mentally go through the taint flags and the letters to map them back to the human-readable description.
|
| 63/2 |
2026/05/15 18:21 |
tool |
grepper |
0m
Args: map[Expression:taint_flags]
Results: map[Output:include/linux/module.h=397=struct module {
--
include/linux/module.h-459-
include/linux/module.h:460: unsigned long taints; /* same bits as kernel:taint_flags */
include/linux/module.h-461-
--
include/linux/panic.h=94=struct taint_flag {
--
include/linux/panic.h-99-
include/linux/panic.h:100:extern const struct taint_flag taint_flags[TAINT_FLAGS_COUNT];
include/linux/panic.h-101-
--
kernel/module/main.c=951=size_t module_flags_taint(unsigned long taints, char *buf)
--
kernel/module/main.c-957- if (test_bit(i, &taints))
kernel/module/main.c:958: buf[l++] = taint_flags[i].c_true;
kernel/module/main.c-959- }
--
kernel/panic.c=790=EXPORT_SYMBOL(panic);
--
kernel/panic.c-798-/*
kernel/panic.c:799: * NOTE: if you modify the taint_flags or TAINT_FLAGS_COUNT,
kernel/panic.c-800- * please also modify tools/debugging/kernel-chktaint and
--
kernel/panic.c-804- */
kernel/panic.c:805:const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
kernel/panic.c-806- TAINT_FLAG(PROPRIETARY_MODULE, 'P', 'G'),
--
kernel/panic.c=830=static void print_tainted_seq(struct seq_buf *s, bool verbose)
--
kernel/panic.c-841- for (i = 0; i < TAINT_FLAGS_COUNT; i++) {
kernel/panic.c:842: const struct taint_flag *t = &taint_flags[i];
kernel/panic.c-843- bool is_set = test_bit(i, &tainted_mask);
--
kernel/panic.c=857=static const char *_print_tainted(bool verbose)
--
kernel/panic.c-859- /* FIXME: what should the size be? */
kernel/panic.c:860: static char buf[sizeof(taint_flags)];
kernel/panic.c-861- struct seq_buf s;
kernel/panic.c-862-
kernel/panic.c:863: BUILD_BUG_ON(ARRAY_SIZE(taint_flags) != TAINT_FLAGS_COUNT);
kernel/panic.c-864-
]
|
| 64/2 |
2026/05/15 18:21 |
llm |
expert |
0m
Model:
Tokens:
input: 80173
output: 38
thoughts: 19
Thoughts: Here's my summary, as though I'm thinking through this process:
**Diving into Kernel Panic: Tracking Taint Flags**
Alright, let's get down to brass tacks. I need to understand how the kernel handles and reports "taint" states during a panic. My focus right now is on the code responsible for panic handling, and that naturally leads me to `kernel/panic.c`. Specifically, I'm expecting to find the implementation or usage of `taint_flags` within that file. I'm keen to see how these flags are set, cleared, and most importantly, how they might be reported or utilized when the system hits a fatal error. Understanding the connection between a panic and the propagation of taint is crucial for debugging and diagnosing the root causes of kernel issues. Let's see what we find!
|
| 65/2 |
2026/05/15 18:22 |
tool |
codesearch-definition-source |
0m
Args: map[ContextFile:kernel/panic.c IncludeLines:true Name:taint_flags]
Results: map[SourceCode: 798: /*
799: * NOTE: if you modify the taint_flags or TAINT_FLAGS_COUNT,
800: * please also modify tools/debugging/kernel-chktaint and
801: * Documentation/admin-guide/tainted-kernels.rst, including its
802: * small shell script that prints the TAINT_FLAGS_COUNT bits of
803: * /proc/sys/kernel/tainted.
804: */
805: const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
806: TAINT_FLAG(PROPRIETARY_MODULE, 'P', 'G'),
807: TAINT_FLAG(FORCED_MODULE, 'F', ' '),
808: TAINT_FLAG(CPU_OUT_OF_SPEC, 'S', ' '),
809: TAINT_FLAG(FORCED_RMMOD, 'R', ' '),
810: TAINT_FLAG(MACHINE_CHECK, 'M', ' '),
811: TAINT_FLAG(BAD_PAGE, 'B', ' '),
812: TAINT_FLAG(USER, 'U', ' '),
813: TAINT_FLAG(DIE, 'D', ' '),
814: TAINT_FLAG(OVERRIDDEN_ACPI_TABLE, 'A', ' '),
815: TAINT_FLAG(WARN, 'W', ' '),
816: TAINT_FLAG(CRAP, 'C', ' '),
817: TAINT_FLAG(FIRMWARE_WORKAROUND, 'I', ' '),
818: TAINT_FLAG(OOT_MODULE, 'O', ' '),
819: TAINT_FLAG(UNSIGNED_MODULE, 'E', ' '),
820: TAINT_FLAG(SOFTLOCKUP, 'L', ' '),
821: TAINT_FLAG(LIVEPATCH, 'K', ' '),
822: TAINT_FLAG(AUX, 'X', ' '),
823: TAINT_FLAG(RANDSTRUCT, 'T', ' '),
824: TAINT_FLAG(TEST, 'N', ' '),
825: TAINT_FLAG(FWCTL, 'J', ' '),
826: };
SourceFile:kernel/panic.c]
|
| 66/2 |
2026/05/15 18:22 |
llm |
expert |
0m
Model:
Tokens:
input: 81039
output: 66
thoughts: 751
Thoughts: **My Analysis of the Kernel Panic**
Okay, so here's what I've pieced together. The `L` in the `Tainted: [L]=SOFTLOCKUP` flag is the key. It confirms my initial hunch – we're dealing with a softlockup scenario. The sequence of events is exactly as I predicted.
First, a softlockup occurred – a CPU stuck in an endless or extended loop, lasting longer than the 20-second threshold. Then, as designed, the softlockup watchdog timer interrupt kicked in. It did its job, printed a warning and, importantly, called `dump_stack`. Now, this is where things get interesting. `dump_stack`, as we know, pushes a significant number of stack frames onto the task stack.
The problem, and this is where the vulnerability lies, is that the stack was likely already quite full. This is because of the initial loop, possibly a deep call chain or softirq. Thus, when `dump_stack` attempted to add its frames, it overflowed the stack. The overflow wasn't just random data; it overwrote `init_stack[0]`, specifically `STACK_END_MAGIC`. The corrupted value observed, `0x8280001c`, is near the bottom of the stack. This implies that we overwrote stack frame information, which is consistent with `dump_stack`'s behavior.
The watchdog interrupt returned, and eventually, the loop completed or exited. The CPU returned to idle and `do_idle` called `schedule_idle`, which in turn called `__schedule`. `__schedule` has a check on `STACK_END_MAGIC`. The check failed. The panic occurred because this stack end magic was corrupted.
So, in essence, we have a classic Denial of Service vulnerability, triggered by a softlockup, which then caused a secondary stack overflow through the watchdog. The overflow itself isn't directly exploitable for privilege escalation – we're not dealing with attacker-controlled data being overwritten; it's `dump_stack` pushing return addresses and frame pointers. The primary issue is the initial softlockup. It’s the DoS that makes this a problem.
Since syzkaller triggered this, we know it's reachable from unprivileged processes and user namespaces. We don't have the specific trigger from syzkaller, which means it could originate from network-related code, a filesystem operation, or somewhere else. We err on the side of caution and mark these potential triggers as unknown.
Therefore, to recap:
- The fundamental issue is a stack overflow of the idle thread (`swapper/0`) stack.
- The `SOFTLOCKUP` taint flag is the smoking gun.
- The watchdog's call to `dump_stack` is the immediate cause of the overflow, pushed to the interrupt.
- The `dump_stack` overflow is due to the deep call chain and/or softirq.
- The corrupted `STACK_END_MAGIC` confirms the overflow location and type.
- The root cause is the softlockup caused by syzkaller.
- The softlockup itself is a DoS vulnerability.
- While the stack overflow is a secondary consequence, it is not exploitable for privilege escalation.
- This DoS is accessible via unprivileged processes and user namespaces.
- Trigger details are unknown.
Alright, I'm going to call `set-results` to record this analysis.
|
| 67/2 |
2026/05/15 18:22 |
tool |
set-results |
0m
Args: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
Results: map[DenialOfService:true Exploitable:false FilesystemTrigger:false NetworkTrigger:false PeripheralTrigger:false RemoteTrigger:false Unprivileged:true UserNamespace:true VMGuestTrigger:false VMHostTrigger:false]
|
| 68/2 |
2026/05/15 18:22 |
llm |
expert |
0m
Model:
Tokens:
input: 82656
output: 646
thoughts: 13
Thoughts: Okay, here's my attempt at summarizing the thought process, tailored for an expert audience, and written in the first person:
**Finalizing the Analysis & Drafting the Response**
Alright, the data is processed, the analyses are complete, and the results are definitive. There's no further tweaking, no more sensitivity analyses needed. Now it's time to craft the final response. This isn't just about regurgitating the findings; it's about synthesizing the entire process – the methodology, the nuances of the data, the interpretation of the output, and ultimately, articulating the implications with precision and clarity. I need to ensure the language is concise, technically sound, and accessible to the intended audience, while also avoiding any ambiguity. The emphasis needs to be on the robustness of the results, and, of course, the limitations are always in mind. Now, the goal is to make a compelling argument and leave no room for misinterpretation. Time to get to work.
|
| 69/1 |
2026/05/15 18:22 |
action |
format-explanation |
0m
Results: map[Explanation:The analysis of the bug report reveals the following sequence of events:
1. **The Panic**: The kernel panicked with `corrupted stack end detected inside
scheduler`. This happens in `__schedule()` when it checks the `STACK_END_MAGIC`
at the bottom of the task's stack and finds it overwritten.
2. **The Victim**: The panic occurred in `swapper/0` (PID 0), which is the idle
thread. Its stack is statically allocated as `init_stack`.
3. **The Corrupted Value**: The registers dump shows `r3:57ac6e9d` (which is the
expected `STACK_END_MAGIC`) and `r2:8280001c`. Given that `init_stack` is
typically aligned to `THREAD_SIZE` (e.g., `0x82800000`), `0x8280001c` is an
address exactly `0x1c` bytes into the stack. This strongly indicates that a
stack frame pointer or saved stack pointer was pushed to the very bottom of the
stack, overwriting the magic value.
4. **The Root Cause**: The kernel is tainted with `[L]=SOFTLOCKUP`. This means
that prior to the panic, the CPU was stuck in a loop for at least 20 seconds,
and the softlockup watchdog timer interrupt fired. When the watchdog fires, it
prints a warning and calls `dump_stack()`.
5. **The Mechanism**: If the CPU was stuck in a deep call chain or a softirq
handler (e.g., processing a complex network packet or malicious input), the task
stack was already mostly full. The additional stack frames pushed by the
watchdog's `dump_stack()` caused the stack to overflow, overwriting
`init_stack[0]`. After the watchdog interrupt returned, the long loop eventually
finished, and the CPU returned to the idle loop. When `do_idle()` called
`__schedule()`, the corrupted magic value was detected, triggering the panic.
**Security Impact Assessment:**
* **Exploitable**: **No**. The stack overflow is a secondary effect caused by
the kernel's own `dump_stack()` function pushing return addresses and frame
pointers. It does not involve attacker-controlled data being written
out-of-bounds, making it unexploitable for privilege escalation or arbitrary
code execution.
* **Denial of Service**: **Yes**. The primary bug is a softlockup (an infinite
or excessively long loop in the kernel), which halts the CPU and leads to a
system crash/panic.
* **Accessible From Unprivileged Processes / User Namespaces**: **Yes**.
Syzkaller runs as an unprivileged user (often within user namespaces) and was
able to trigger the softlockup, indicating that no special privileges are
required.
* **Specific Triggers**: Unknown. The exact subsystem (network, filesystem,
etc.) where the softlockup occurred is not specified in the trace. We err on the
side of caution and assume they are not specifically required.]
|