CVE-2026-68139

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 MLX5DRIVEREVENTAFFILIATIONDONE and mlx5e sent MPVDEVCOMMASTER_UP. The host then panicked with:

BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5devcomcompsetready+0x5/0x40 [mlx5_core] RDI: 0000000000000000

Call trace included:

mlx5devcomcompsetready mlx5edevcomeventmpv mlx5devcomsendevent mlx5ibbindslaveport mlx5rmpprobe mlx5pciresume

MPV devcom registration publishes mlx5e private data to the component peer list before mlx5edevcominit_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.

MPVDEVCOMMASTERUP already carries the sender/master mlx5e private data as eventdata. 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.