CVE-2026-68139net/mlx5e: Use sender devcom for MPV master-up
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Aug 17, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from bf11485f8419f90ffaa3804fd01d8468fcc56e23 before c698b2735613f1f35c55688bd2252f75f31c49ad; from bf11485f8419f90ffaa3804fd01d8468fcc56e23 before 40f9a124ebbe0d60fe165fb3f87515c35b2d72f5; from bf11485f8419f90ffaa3804fd01d8468fcc56e23 before a60c81f168c9fe4f5d84302d1e32b717f5a8a933; from bf11485f8419f90ffaa3804fd01d8468fcc56e23 before e32649b4bad90a6216d8e93cd7dd050af8ac9740 | CNA record |
References
- https://git.kernel.org/stable/c/c698b2735613f1f35c55688bd2252f75f31c49ad
- https://git.kernel.org/stable/c/40f9a124ebbe0d60fe165fb3f87515c35b2d72f5
- https://git.kernel.org/stable/c/a60c81f168c9fe4f5d84302d1e32b717f5a8a933
- https://git.kernel.org/stable/c/e32649b4bad90a6216d8e93cd7dd050af8ac9740
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.