cve/2024/CVE-2024-57838.md
2025-09-29 21:09:30 +02:00

2.3 KiB

CVE-2024-57838

Description

In the Linux kernel, the following vulnerability has been resolved:s390/entry: Mark IRQ entries to fix stack depot warningsThe stack depot filters out everything outside of the top interruptcontext as an uninteresting or irrelevant part of the stack traces. Thishelps with stack trace de-duplication, avoiding an explosion of savedstack traces that share the same IRQ context code path but originatefrom different randomly interrupted points, eventually exhausting thestack depot.Filtering uses in_irqentry_text() to identify functions within the.irqentry.text and .softirqentry.text sections, which then become thelast stack trace entries being saved.While __do_softirq() is placed into the .softirqentry.text section bycommon code, populating .irqentry.text is architecture-specific.Currently, the .irqentry.text section on s390 is empty, which preventsstack depot filtering and de-duplication and could result in warningslike:Stack depot reached limit capacityWARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8with PREEMPT and KASAN enabled.Fix this by moving the IO/EXT interrupt handlers from .kprobes.text intothe .irqentry.text section and updating the kprobes blacklist to includethe .irqentry.text section.This is done only for asynchronous interrupts and explicitly not forprogram checks, which are synchronous and where the context beyond theprogram check is important to preserve. Despite machine checks beingsomewhat in between, they are extremely rare, and preserving contextwhen possible is also of value.SVCs and Restart Interrupts are not relevant, one being always at theboundary to user space and the other being a one-time thing.IRQ entries filtering is also optionally used in ftrace function graph,where the same logic applies.

POC

Reference

No PoCs from references.

Github