CVE-2024-50040 in Linux
Summary
by MITRE • 10/21/2024
In the Linux kernel, the following vulnerability has been resolved:
igb: Do not bring the device up after non-fatal error
Commit 004d25060c78 ("igb: Fix igb_down hung on surprise removal") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below.
[ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down
[ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0
[ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
[ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000
[ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000
[ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message
[ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported.
[ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message
[ T292] pcieport 0000:00:1c.5: AER: broadcast resume message
[ T292] ------------[ cut here ]------------
[ T292] kernel BUG at net/core/dev.c:6539!
[ T292] invalid opcode: 0000 [#1] PREEMPT SMP
[ T292] RIP: 0010:napi_enable+0x37/0x40
[ T292] Call Trace:
[ T292]
[ T292] ? die+0x33/0x90
[ T292] ? do_trap+0xdc/0x110
[ T292] ? napi_enable+0x37/0x40
[ T292] ? do_error_trap+0x70/0xb0
[ T292] ? napi_enable+0x37/0x40
[ T292] ? napi_enable+0x37/0x40
[ T292] ? exc_invalid_op+0x4e/0x70
[ T292] ? napi_enable+0x37/0x40
[ T292] ? asm_exc_invalid_op+0x16/0x20
[ T292] ? napi_enable+0x37/0x40
[ T292] igb_up+0x41/0x150
[ T292] igb_io_resume+0x25/0x70
[ T292] report_resume+0x54/0x70
[ T292] ? report_frozen_detected+0x20/0x20
[ T292] pci_walk_bus+0x6c/0x90
[ T292] ? aer_print_port_info+0xa0/0xa0
[ T292] pcie_do_recovery+0x22f/0x380
[ T292] aer_process_err_devices+0x110/0x160
[ T292] aer_isr+0x1c1/0x1e0
[ T292] ? disable_irq_nosync+0x10/0x10
[ T292] irq_thread_fn+0x1a/0x60
[ T292] irq_thread+0xe3/0x1a0
[ T292] ? irq_set_affinity_notifier+0x120/0x120
[ T292] ? irq_affinity_notify+0x100/0x100
[ T292] kthread+0xe2/0x110
[ T292] ? kthread_complete_and_exit+0x20/0x20
[ T292] ret_from_fork+0x2d/0x50
[ T292] ? kthread_complete_and_exit+0x20/0x20
[ T292] ret_from_fork_asm+0x11/0x20
[ T292]
To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/22/2026
The vulnerability described in CVE-2024-50040 affects the Linux kernel's igb network driver, which manages Intel Gigabit Ethernet controllers. This issue stems from an improper handling of PCIe non-fatal errors during device recovery operations. The root cause lies in the interaction between the error detection and recovery functions within the driver's implementation. When a non-fatal PCIe error occurs, the igb_io_error_detected() function was modified to ignore such errors to prevent potential system hangs, but this change created a logic inconsistency in the recovery flow. The problem manifests when transient non-fatal errors are processed, causing the device state to become inconsistent between error detection and recovery phases.
The technical flaw occurs in the sequence of operations during PCIe error recovery where the igb_io_resume() function makes incorrect assumptions about device state. Specifically, this function assumes that if a network interface is up, then igb_io_error_detected() must have brought the device down, which is no longer true after the aforementioned code change. This assumption leads to a critical error condition when the driver attempts to bring the device up again without proper validation of its actual state. The kernel panic occurs at the napi_enable() function call within igb_up(), which is invoked by igb_io_resume(), resulting in an invalid opcode execution that crashes the system. This vulnerability directly relates to CWE-697, which covers inadequate error handling and incorrect assumptions about system state, and maps to ATT&CK technique T1490 for Deobfuscation of Network Traffic, as the error handling mechanism itself becomes corrupted.
The operational impact of this vulnerability is severe as it can cause complete system crashes or kernel panics during normal network operation when non-fatal PCIe errors occur. Systems using Intel Gigabit Ethernet controllers are particularly vulnerable, especially in server environments where network reliability is critical. The vulnerability affects the stability of network operations and can lead to unexpected service disruptions. Recovery from such panics typically requires manual system reboot, causing downtime that can be particularly problematic in production environments. The issue is exacerbated by the fact that non-fatal PCIe errors are common in network hardware operations and can occur due to various factors including electromagnetic interference, power fluctuations, or hardware aging. The fix implemented addresses the core problem by modifying igb_io_resume() to properly check whether the device was actually brought down by the error detection routine before attempting to bring it back up, preventing the invalid state transition that leads to the kernel panic. This mitigation aligns with security best practices for error recovery in kernel space drivers and follows the principle of least privilege by ensuring state transitions are properly validated before execution.