CVE-2024-57916

What it actually does

Improper IRQ handling in the microchip pci1xxxx GPIO driver causes a kernel panic when accessing GPIO values due to incorrect use of generic_handle_irq instead of handle_nested_irq in a race condition scenario.

Why it matters to the business

Systems may experience unexpected crashes and downtime when GPIO interrupts are processed on affected Linux kernel configurations, disrupting operations that rely on stable hardware access.

How an attack unfolds

An attacker with local access triggers concurrent GPIO IRQ events that race during value access, leading the kernel to mishandle nested interrupts and panic; no named threat actors are associated with active exploitation of this issue.

How to fix it

Update the Linux kernel to commit 79aef6187e16b2d32307c8ff610e9e04f7f86e1f or later. For Red Hat Enterprise Linux 7 hypervisor packages, upgrade to version 10:2.3.0-31.el7_2.13 or newer of the affected qemu-kvm-rhev, libcacard, and related components.

How to confirm the fix worked

Verify the running kernel contains commit 79aef6187e16b2d32307c8ff610e9e04f7f86e1f and confirm Red Hat packages report version 10:2.3.0-31.el7_2.13 or higher; test GPIO IRQ workloads to ensure no panics occur.

Typical attack path

1. Obtain local code execution on a system using the pci1xxxx GPIO driver
2. Trigger concurrent access to GPIO values while IRQs are active
3. Cause the kernel to call generic_handle_irq in a nested context
4. Induce a panic that crashes the system

How to detect it

Review kernel logs for panic messages mentioning microchip pci1xxxx GPIO or IRQ handling errors; examine dmesg and syslog for nested IRQ warnings around the time of any crashes.

What your security team should do

• Prioritize kernel and hypervisor package updates on all systems using pci1xxxx hardware
• Monitor for kernel oops or panic logs related to GPIO IRQ handling
• Apply updates before the next scheduled maintenance window given the low but present exploitation probability