CVE-2023-54322
Stack Overflow Risk in Linux arm64 Kernel IRQ Handling
Publication date: 2025-12-30
Last updated on: 2025-12-30
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the Linux kernel's arm64 architecture relates to how the kernel handles interrupt request (IRQ) entries in the call stack. Specifically, the function filter_irq_stacks() is supposed to remove IRQ-related entries from the call stack using in_irqentry_text(), which relies on certain symbols (__irqentry_text_start/end) to identify IRQ entries. However, without the CONFIG_FUNCTION_GRAPH_TRACER configuration, the arm64 kernel does not include the gic_handle_irq function (the entry point for arm64 IRQs) within these symbols. This causes the filter to fail, resulting in unintentional deep call stack entries, especially when Kernel Address Sanitizer (KASAN) is enabled, potentially leading to stack depot capacity issues and warnings in the kernel logs.
How can this vulnerability impact me? :
The impact of this vulnerability is primarily related to kernel debugging and memory error detection tools like KASAN. Because the IRQ entries are not properly filtered from the call stack, it can cause excessively deep call stacks to be recorded unintentionally. This can lead to warnings such as 'Stack depot reached limit capacity' and may affect the reliability or performance of debugging and memory error detection mechanisms. It does not directly indicate a security breach but can complicate kernel diagnostics and stability under certain configurations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as unintentional deep call stack entries, especially in KASAN enabled situations, with kernel log messages such as 'Stack depot reached limit capacity' and warnings related to __stack_depot_save. To detect it, monitor your kernel logs (e.g., using 'dmesg' or 'journalctl -k') for these specific warning messages. Example commands: 'dmesg | grep "Stack depot reached limit capacity"' or 'journalctl -k | grep __stack_depot_save'.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the Linux kernel to a version where this vulnerability is resolved, as it relates to the arm64 kernel's handling of irq entries in the call stack. If updating is not immediately possible, monitoring for the described kernel warnings and limiting workloads that trigger deep call stacks under KASAN may help reduce impact. Enabling CONFIG_FUNCTION_GRAPH_TRACER may also affect the behavior, but the primary fix is a kernel update.