CVE-2024-57838

s390/entry: Mark IRQ entries to fix stack depot warnings

Published Jan 11, 2025 CVSS 3.1 · 7.1 High EPSS < 1% KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:

s390/entry: Mark IRQ entries to fix stack depot warnings

The stack depot filters out everything outside of the top interrupt
context as an uninteresting or irrelevant part of the stack traces. This
helps with stack trace de-duplication, avoiding an explosion of saved
stack traces that share the same IRQ context code path but originate
from different randomly interrupted points, eventually exhausting the
stack depot.

Filtering uses in_irqentry_text() to identify functions within the
.irqentry.text and .softirqentry.text sections, which then become the
last stack trace entries being saved.

While __do_softirq() is placed into the .softirqentry.text section by
common code, populating .irqentry.text is architecture-specific.

Currently, the .irqentry.text section on s390 is empty, which prevents
stack depot filtering and de-duplication and could result in warnings
like:

Stack depot reached limit capacity
WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8

with PREEMPT and KASAN enabled.

Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into
the .irqentry.text section and updating the kprobes blacklist to include
the .irqentry.text section.

This is done only for asynchronous interrupts and explicitly not for
program checks, which are synchronous and where the context beyond the
program check is important to preserve. Despite machine checks being
somewhat in between, they are extremely rare, and preserving context
when possible is also of value.

SVCs and Restart Interrupts are not relevant, one being always at the
boundary 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.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Debian DLA Debian DLA DLA-4076-1 linux-6.1 security update
EUVD EUVD EUVD-2024-53768 In the Linux kernel, the following vulnerability has been resolved: s390/entry: Mark IRQ entries to fix stack depot warnings The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved. While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific. Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like: Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section. This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value. SVCs and Restart Interrupts are not relevant, one being always at the boundary 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.
Ubuntu USN Ubuntu USN USN-7379-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7379-2 Linux kernel (Raspberry Pi) vulnerabilities
Ubuntu USN Ubuntu USN USN-7380-1 Linux kernel (Low Latency) vulnerabilities
Ubuntu USN Ubuntu USN USN-7381-1 Linux kernel (Low Latency) vulnerabilities
Ubuntu USN Ubuntu USN USN-7382-1 Linux kernel (OEM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7387-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7387-2 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7387-3 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7388-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7389-1 Linux kernel (NVIDIA Tegra) vulnerabilities
Ubuntu USN Ubuntu USN USN-7390-1 Linux kernel (Xilinx ZynqMP) vulnerabilities
Ubuntu USN Ubuntu USN USN-7407-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7421-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-7449-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7449-2 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-7450-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7451-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7452-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7453-1 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7458-1 Linux kernel (IBM) vulnerabilities
Ubuntu USN Ubuntu USN USN-7459-1 Linux kernel (Intel IoTG) vulnerabilities
Ubuntu USN Ubuntu USN USN-7459-2 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-7468-1 Linux kernel (Azure, N-Series) vulnerabilities
Ubuntu USN Ubuntu USN USN-7523-1 Linux kernel (Raspberry Pi Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7524-1 Linux kernel (Raspberry Pi) vulnerabilities
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Weaknesses CWE-668
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 4.4, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 7.1, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H'}

Type Values Removed Values Added
Weaknesses CWE-770
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

cvssV3_1

{'score': 4.4, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H'}

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: s390/entry: Mark IRQ entries to fix stack depot warnings The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved. While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific. Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like: Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section. This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value. SVCs and Restart Interrupts are not relevant, one being always at the boundary 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.
Title s390/entry: Mark IRQ entries to fix stack depot warnings
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Nov 5, 2026, 8:41 PM
Reserved
Jan 11, 2025, 12:32 PM
Status
Modified
Published
Jan 11, 2025, 2:15 PM
Modified
Nov 5, 2026, 9:17 PM
Severity
Low
Public date
Jan 11, 2025, 12:00 AM