CVE-2026-68139 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Use sender devcom for MPV master-up
After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was:
pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First)
mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with:
BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]
RDI: 0000000000000000
Call trace included:
mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume
MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL.
MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready.
This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability resides within the linux kernel's mlx5 network driver, specifically in how it handles multiport virtualization (MPV) operations during pci error recovery processes. When a pci device experiences a correctable or uncorrectable error requiring a dpc (downstream port containment) recovery, the system must reload affected pci functions and replay multiport affiliation events to restore normal operation. The reported issue occurred during such a recovery scenario where the mlx5 driver attempted to resume a pci function at 0000:11:00.1 following a pcie bus error with severity level fatal. During this recovery process, the rdma multiport binding system replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and subsequently triggered mlx5e sent MPV_DEVCOM_MASTER_UP events to notify other components of the master's readiness.
The core technical flaw stems from an improper ordering of operations within the driver's initialization sequence. During MPV devcom registration, the mlx5e private data is published to the component peer list before the mlx5e_devcom_init_mpv() function stores the returned component device pointer in the private data structure at priv->devcom. This race condition creates a scenario where concurrent master-up events can be processed by peers that have visibility to the private data but whose priv->devcom backpointer remains uninitialized and NULL. The kernel panic occurs when mlx5_devcom_comp_set_ready attempts to access this NULL pointer at address 0x10, causing an immediate null pointer dereference.
This vulnerability directly relates to cwe-476 null pointer dereference and follows patterns commonly seen in concurrent programming where initialization order creates race conditions between component registration and event processing. The attack surface becomes particularly relevant during hardware error recovery scenarios that involve pci hotplug or error containment events, which aligns with attack techniques described in the mitre att&ck framework under system service manipulation and privilege escalation through device driver vulnerabilities. The specific call trace demonstrates a clear path from the kernel's pci resume handler through the mlx5 ib binding layer to the final null pointer dereference, indicating this is not an isolated event but rather a fundamental synchronization issue within the driver's multiport virtualization implementation.
The recommended mitigation involves modifying the MPV devcom event handling logic to utilize the sender's devcom reference when marking the component ready, rather than relying on potentially uninitialized peer references. This approach preserves the intended readiness transition while ensuring that all operations occur on properly initialized component structures. The fix essentially moves away from using peer-specific devcom pointers during the ready bit setting operation and instead leverages the sender devcom context that is guaranteed to be valid. This solution addresses the root cause by eliminating the race condition through proper reference management and initialization ordering, preventing the kernel panic while maintaining all existing functionality. The implementation should ensure backward compatibility with existing driver interfaces and maintain proper synchronization between the various components involved in multiport virtualization operations during hardware error recovery scenarios.