CVE-2024-49927
NoneCVSS
—
EPSS
0.2%
Published
Oct 21, 2024
CISA due date
—
Cloudanix analysis
A problem in the Linux kernel could make computers crash and restart when they run low on memory while setting up certain hardware connections.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability causes a kernel panic in mp_irqdomain_alloc when __add_pin_to_irq_node encounters an allocation failure for irq_pin_list during runtime IO-APIC pin mapping for ACPI or HPET devices, instead of propagating the error gracefully.
Why it matters to the business
Unexpected system crashes and reboots occur under memory pressure or allocation failure conditions during hardware interrupt setup, leading to unplanned downtime on affected Linux systems.
How an attack unfolds
An attacker or environmental condition induces memory allocation failures during ACPI GSI registration or HPET open operations that invoke mp_map_pin_to_irq; the unhandled failure in the IO-APIC domain allocation path triggers the legacy panic instead of falling back or returning an error.
How to fix it
Upgrade the Linux kernel to a version containing commit e479cb835feeb2abff97f25766e23b96a6eabe28 or later; apply the equivalent fixed package such as mod_md 1:2.0.8-8.module+el8.5.0+695+1fa8055e on Rocky Linux 8.
How to confirm the fix worked
Confirm the running kernel includes the referenced commit or patched package; reproduce allocation failure scenarios with tools such as failslab and verify graceful error handling without panic.
Typical attack path
- Trigger low-memory or failslab conditions on a running system
- Initiate operations that register IO-APIC routed interrupts such as HPET timer access or ACPI device initialization
- Cause allocation failure inside mp_irqdomain_alloc leading to unhandled panic in __add_pin_to_irq_node
How to detect it
Search kernel logs and dmesg output for panic strings referencing IO-APIC allocation failures or irq_pin_list; correlate with ACPI or HPET initialization events around the time of crash.
- can not alloc irq_pin_list
- Kernel panic - not syncing: IO-APIC: failed to add irq-pin
- mp_irqdomain_alloc
- mp_map_pin_to_irq
What your security team should do
- Prioritize kernel updates on all affected systems given the public fix and potential for environmental triggering
- Review kernel logs for prior occurrences of 'can not alloc irq_pin_list' messages
- Enable memory pressure monitoring and testing in CI environments to validate interrupt allocation resilience
The record
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Debian:11 | linux | 0 | No fix |
| Debian:11 | linux-6.1 | 0 | 6.1.119-1~deb11u1 |
| Debian:12 | linux | 0 | No fix |
| Debian:13 | linux | 0 | No fix |
| Debian:13 | linux | 0 | 6.11.4-1 |
| Linux | Kernel | 0 | 5.15.168 |
| Linux | Kernel | 4.2.0 | 5.15.168 |
| Mageia:9 | kernel | 0 | 6.6.58-2.mga9 |
| Mageia:9 | kernel-firmware | 0 | 20240909-1.mga9 |
| Mageia:9 | kernel-firmware-nonfree | 0 | 20240909-1.mga9.nonfree |
| Mageia:9 | kernel-linus | 0 | 6.6.58-2.mga9 |
| Mageia:9 | kmod-virtualbox | 0 | 7.0.20-57.mga9 |
| Mageia:9 | kmod-xtables-addons | 0 | 3.24-65.mga9 |
| Mageia:9 | radeon-firmware | 0 | 20240909-1.mga9.nonfree |
| Ubuntu:20.04:LTS | linux-aws-5.15 | 0 | 5.15.0-1073.79~20.04.1 |
| Ubuntu:20.04:LTS | linux-azure-5.15 | 0 | 5.15.0-1078.87~20.04.1 |
| Ubuntu:20.04:LTS | linux-gcp-5.15 | 0 | 5.15.0-1072.80~20.04.1 |
| Ubuntu:20.04:LTS | linux-hwe-5.15 | 0 | 5.15.0-127.137~20.04.1 |
| Ubuntu:20.04:LTS | linux-ibm-5.15 | 0 | 5.15.0-1066.69~20.04.1 |
| Ubuntu:20.04:LTS | linux-intel-iotg-5.15 | 0 | 5.15.0-1071.77~20.04.1 |
| Ubuntu:20.04:LTS | linux-lowlatency-hwe-5.15 | 0 | 5.15.0-127.137~20.04.1 |
| Ubuntu:20.04:LTS | linux-oracle-5.15 | 0 | 5.15.0-1071.77~20.04.1 |
| Ubuntu:22.04:LTS | linux | 0 | 5.15.0-127.137 |
| Ubuntu:22.04:LTS | linux-aws | 0 | 5.15.0-1073.79 |
| Ubuntu:22.04:LTS | linux-azure | 0 | 5.15.0-1078.87 |
| Ubuntu:22.04:LTS | linux-gcp | 0 | 5.15.0-1072.80 |
| Ubuntu:22.04:LTS | linux-gke | 0 | 5.15.0-1070.76 |
| Ubuntu:22.04:LTS | linux-gkeop | 0 | 5.15.0-1056.63 |
| Ubuntu:22.04:LTS | linux-ibm | 0 | 5.15.0-1066.69 |
| Ubuntu:22.04:LTS | linux-intel-iotg | 0 | 5.15.0-1071.77 |
| Ubuntu:22.04:LTS | linux-kvm | 0 | 5.15.0-1070.75 |
| Ubuntu:22.04:LTS | linux-lowlatency | 0 | 5.15.0-127.137 |
| Ubuntu:22.04:LTS | linux-nvidia | 0 | 5.15.0-1068.69 |
| Ubuntu:22.04:LTS | linux-oracle | 0 | 5.15.0-1071.77 |
| Ubuntu:22.04:LTS | linux-raspi | 0 | 5.15.0-1066.69 |
| Ubuntu:22.04:LTS | linux-xilinx-zynqmp | 0 | 5.15.0-1039.43 |
| Ubuntu:24.10 | linux | 0 | 6.11.0-18.18 |
| Ubuntu:24.10 | linux-aws | 0 | 6.11.0-1009.10 |
| Ubuntu:24.10 | linux-azure | 0 | 6.11.0-1009.9 |
| Ubuntu:24.10 | linux-gcp | 0 | 6.11.0-1009.9 |
| Ubuntu:24.10 | linux-lowlatency | 0 | 6.11.0-1010.11 |
| Ubuntu:24.10 | linux-oracle | 0 | 6.11.0-1011.12 |
| Ubuntu:24.10 | linux-raspi | 0 | 6.11.0-1008.8 |
| Ubuntu:24.10 | linux-realtime | 0 | 6.11.0-1005.5 |
| openSUSE:Tumbleweed | kernel-source | 0 | 6.11.8-1.1 |
| openSUSE:Tumbleweed | kernel-source-longterm | 0 | 6.12.11-1.1 |
Related vulnerabilities
- CVE-2025-39885 In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix recursive… Also affects linux
- CVE-2025-39883 In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure… Also affects linux
- CVE-2025-39876 In the Linux kernel, the following vulnerability has been resolved: net: fec: Fix… Also affects linux
- CVE-2025-39869 In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma… Also affects linux
- CVE-2025-39873 In the Linux kernel, the following vulnerability has been resolved: can: xilinx_can… Also affects linux
- CVE-2025-39863 In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix… Also affects linux
- CVE-2025-39865 In the Linux kernel, the following vulnerability has been resolved: tee: fix NULL pointer… Also affects linux
- CVE-2025-39866 In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix… Also affects linux