CVE-2025-68790: net/mlx5: Fix double unregister of HCA_PORTS component
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix double unregister of HCA_PORTS component
Clear hca_devcom_comp in device's private data after unregistering it in
LAG teardown. Otherwise a slightly lagging second pass through
mlx5_unload_one() might try to unregister it again and trip over
use-after-free.
On s390 almost all PCI level recovery events trigger two passes through
mxl5_unload_one() - one through the poll_health() method and one through
mlx5_pci_err_detected() as callback from generic PCI error recovery.
While testing PCI error recovery paths with more kernel debug features
enabled, this issue reproducibly led to kernel panics with the following
call chain:
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803 ESOP-2 FSI
Fault in home space mode while using kernel ASCE.
AS:00000000705c4007 R3:0000000000000024
Oops: 0038 ilc:3 [#1]SMP
CPU: 14 UID: 0 PID: 156 Comm: kmcheck Kdump: loaded Not tainted
6.18.0-20251130.rc7.git0.16131a59cab1.300.fc43.s390x+debug #1 PREEMPT
Krnl PSW : 0404e00180000000 0000020fc86aa1dc (__lock_acquire+0x5c/0x15f0)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000000 0000020f00000001 6b6b6b6b6b6b6c33 0000000000000000
0000000000000000 0000000000000000 0000000000000001 0000000000000000
0000000000000000 0000020fca28b820 0000000000000000 0000010a1ced8100
0000010a1ced8100 0000020fc9775068 0000018fce14f8b8 0000018fce14f7f8
Krnl Code: 0000020fc86aa1cc: e3b003400004 lg %r11,832
0000020fc86aa1d2: a7840211 brc 8,0000020fc86aa5f4
*0000020fc86aa1d6: c09000df0b25 larl %r9,0000020fca28b820
>0000020fc86aa1dc: d50790002000 clc 0(8,%r9),0(%r2)
0000020fc86aa1e2: a7840209 brc 8,0000020fc86aa5f4
0000020fc86aa1e6: c0e001100401 larl %r14,0000020fca8aa9e8
0000020fc86aa1ec: c01000e25a00 larl %r1,0000020fca2f55ec
0000020fc86aa1f2: a7eb00e8 aghi %r14,232
Call Trace:
__lock_acquire+0x5c/0x15f0
lock_acquire.part.0+0xf8/0x270
lock_acquire+0xb0/0x1b0
down_write+0x5a/0x250
mlx5_detach_device+0x42/0x110 [mlx5_core]
mlx5_unload_one_devl_locked+0x50/0xc0 [mlx5_core]
mlx5_unload_one+0x42/0x60 [mlx5_core]
mlx5_pci_err_detected+0x94/0x150 [mlx5_core]
zpci_event_attempt_error_recovery+0xcc/0x388
Security readout for executives and security teams
Plain-English summary
CVE-2025-68790 is a Linux kernel bug in the mlx5 network driver. During certain device teardown and PCI error recovery flows, the kernel can try to unregister the same component twice, causing a use-after-free and kernel panic. The public record describes reproducible crashes in debug testing, especially on s390 recovery paths.
Executive priority
Treat as a targeted availability risk for infrastructure using mlx5 networking, especially specialized Linux or s390 environments. It does not currently show evidence of active exploitation, but affected production hosts should receive normal kernel maintenance priority because crashes can disrupt workloads.
Technical view
The issue is in net/mlx5 LAG teardown. hca_devcom_comp was not cleared after unregistering HCA_PORTS, allowing a second mlx5_unload_one() path to unregister it again. The CVE record links this to use-after-free and kernel panic during PCI error recovery, with call traces through mlx5_pci_err_detected() and mlx5_unload_one().
Likely exposure
Most relevant to Linux systems using the mlx5_core driver, LAG-related paths, and PCI error recovery conditions. The source specifically notes s390 where recovery may invoke two unload paths. The listed affected range includes Linux 6.18 through before 6.18.3 and 6.19 data, but version metadata appears limited.
Exploitation context
No public source in the bundle states active exploitation, and KEV is false. The described trigger is a kernel recovery/teardown race-like condition, not a remote application-layer attack. Practical risk is availability impact through kernel panic under specific hardware and recovery circumstances.
Researcher notes
The public description is unusually specific about root cause and call path, but lacks CVSS, CWE, and broad distro status. Avoid assuming exploitability beyond the described panic. The main validation task is mapping downstream kernel packages to the two stable commits and confirming mlx5_core exposure.
Mitigation direction
Review vendor kernel advisories for CVE-2025-68790 and mlx5 fixes.
Apply kernels containing the referenced stable commits when available from your vendor.
Prioritize hosts using mlx5_core with LAG or s390 PCI recovery exposure.
If patching is delayed, monitor for PCI recovery events and kernel panics.
Validation and detection
Inventory Linux kernel versions against the CVE affected range.
Identify systems loading the mlx5_core driver.
Check whether affected systems use LAG or similar mlx5 teardown paths.
Confirm vendor kernel changelogs include the referenced HCA_PORTS unregister fix.
Review crash logs for mlx5_unload_one or mlx5_pci_err_detected traces.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68790 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
3Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 13, 2026, 15:29 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.