CVE-2024-42150

What it actually does

Conflicting IRQ request calls between request_irq for pdev->irq and request_threaded_irq for misc.irq during MSI or INTx initialization cause kernel crash due to duplicate handler registration.

Why it matters to the business

Systems using the affected txgbe network driver in MSI or INTx mode may experience unexpected crashes during driver initialization or interrupt setup, leading to downtime and potential data loss on servers or appliances.

How an attack unfolds

An attacker with local access loads or initializes the txgbe driver on hardware configured for MSI or INTx interrupts; the conflicting IRQ requests trigger the crash. No remote vector or named threat actors are associated.

How to fix it

Update the Linux kernel to commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6 or later; rebuild and deploy the updated kernel image containing the removal of the conflicting txgbe_request_irq call for MSI/INTx cases.

How to confirm the fix worked

Confirm the running kernel contains commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6; verify absence of separate request_irq for pdev->irq in txgbe MSI/INTx paths via source inspection or module load testing on affected hardware.

Typical attack path

1. Obtain local execution or module loading privileges on target system
2. Ensure txgbe driver binds to hardware using MSI or INTx interrupts
3. Trigger driver probe or IRQ setup path
4. Observe kernel panic from IRQ handler conflict

How to detect it

Review kernel logs and dmesg output around driver probe times for messages indicating IRQ request failures or conflicts; monitor for unexpected panics during txgbe initialization on MSI/INTx systems.

What your security team should do

• Prioritize kernel upgrade on systems exposing txgbe hardware within the next maintenance window
• Audit boot logs and dmesg for IRQ request conflicts on production hosts using the driver
• Consider forcing MSIX interrupt mode where hardware supports it as a temporary hardening step