CVE-2024-41021

What it actually does

Triggers a kernel BUG() panic in do_exception() on s390 when VM_FAULT_HWPOISON is encountered together with PTE_MARKER_POISONED, because the architecture lacks HWPOISON support yet the generic PTE marker path can still deliver the fault.

Why it matters to the business

Unexpected kernel crashes on s390 Linux systems can cause unplanned downtime and service interruption; the issue exists in a wide range of stable kernels prior to the referenced commit.

How an attack unfolds

An attacker or local process creates memory mappings that result in a poisoned PTE marker; when the fault is delivered, do_exception() hits the BUG() instead of returning SIGBUS, crashing the system.

How to fix it

Update the Linux kernel to a version containing commit 73a9260b7366d2906ec011e100319359fe2277d0 or later; rebuild and reboot affected s390 systems.

How to confirm the fix worked

Confirm the running kernel includes commit 73a9260b7366d2906ec011e100319359fe2277d0; verify absence of the BUG() path by reviewing do_exception() source or testing fault injection that previously triggered the panic.

Typical attack path

1. Obtain local code execution or trigger memory poisoning via userspace mappings
2. Force a page fault that sets PTE_MARKER_POISONED on s390
3. Observe kernel BUG() and system panic

How to detect it

Search kernel logs and crash dumps for BUG() messages originating from do_exception() that mention unexpected fault flags or VM_FAULT_HWPOISON; correlate with s390 architecture systems.

What your security team should do

• Prioritize patching s390 systems that run recent stable kernels before the fix commit
• Monitor for kernel BUG() reports referencing do_exception and VM_FAULT_HWPOISON
• Apply the update during the next maintenance window if no immediate exposure exists