Look up another CVE · open CVE-2026-64122 in the interactive tracker
CVE-2026-64122
net/mlx5e: Fix use-after-free in mlx5e_tx_reporter_timeout_recover
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-64122 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.12-1 | Update the kernel and reboot. Fixed in 7.0.12-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
mlx5e_tx_reporter_timeout_recover() accesses sq->netdev after mlx5e_safe_reopen_channels() has torn down and freed the channel (and its embedded SQs). Replace the three sq->netdev references with priv->netdev which is safe because priv outlives channel teardown. The netdev_err() call already used priv->netdev for this reason; make the trylock/unlock and health_channel_eq_recover calls consistent. This fixes the following KASAN splat: BUG: KASAN: use-after-free in mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] Read of size 8 at addr ffff889860ed0b28 by task kworker/u113:2/5277 Call Trace: mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] devlink_health_reporter_recover+0xa2/0x150 devlink_health_report+0x254/0x7c0 mlx5e_reporter_tx_timeout+0x297/0x380 [mlx5_core] mlx5e_tx_timeout_work+0x109/0x170 [mlx5_core] process_one_work+0x677/0xf20 worker_thread+0x51f/0xd90 kthread+0x3a5/0x810 ret_from_fork+0x208/0x400 ret_from_fork_asm+0x1a/0x30
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
- What this is
- MELLANOX MLX5 core VPI driverMAINTAINERS section matched on drivers/net/ethernet/mellanox/mlx5/core/ · netdev@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Not established. This site could not find the build rule for the affected file in the kernel trees Debian ships, so it has no answer about whether Debian compiles this code. Read that as unknown, never as absent.
- bookworm, trixie, forky, sid?
- ?
- not established - no Makefile entry for the affected file
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.63%, higher than 49.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18.14 | 6.18.34 | 1604a2d68414 |
| 7.0 | 7.0.11 | 152295aa7dc2 |
| 7.0 | 7.1 | 7d260c5d2d89 |
| 6.19.4 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- The bug is reached from the mlx5e netdev TX-timeout watchdog recovery path on Mellanox ConnectX NICs deployed on internet-facing cloud/datacenter servers; remote peers generate outbound traffic that can stall TX queues and fire `ndo_tx_timeout`, leading to `mlx5e_tx_reporter_timeout_recover()` without any local syscall.
- AC:LAttack complexity, low
- Once a TX timeout occurs, recovery is deterministic: `mlx5e_health_channel_eq_recover()` typically fails when no EQEs are pending, `mlx5e_safe_reopen_channels()` frees the embedded SQ, and the stale `sq->netdev` dereference in `netdev_unlock()` always follows on that fallback path rather than requiring a race the attacker cannot influence.
- PR:NPrivileges required, none
- No capability checks or authentication gates exist on the TX-timeout → devlink health auto-recover call chain; an unauthenticated remote attacker who can send traffic to a host mlx5 interface can induce the watchdog/recovery sequence without root, CAP_NET_ADMIN, or user-namespace privileges.
- UI:NUser interaction, none
- Exploitation requires no victim user action such as mounting a filesystem or opening a file; it is triggered automatically by the kernel netdev watchdog and workqueue recovery once TX queues stall.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption and privilege escalation within the same host kernel security authority; this is not a VM-guest-to-host escape, IOMMU bypass, or other cross-boundary scenario.
- C:HConfidentiality impact, high
- The KASAN splat confirms an 8-byte use-after-free read of `sq->netdev` from freed channel/SQ memory; UAF on this structure pointer can be leveraged for arbitrary kernel memory disclosure via heap reuse and controlled reads through the corrupted `net_device` reference.
- I:HIntegrity impact, high
- The UAF supplies a controlled `struct net_device *` to `netdev_unlock()`, which performs `mutex_unlock()` on attacker-influenced freed memory, enabling heap spraying and memory corruption primitives that can be developed into arbitrary kernel write or code execution.
- A:HAvailability impact, high
- Use-after-free in kernel TX recovery provably causes KASAN faults and can panic or oops the host during `netdev_unlock()` on freed SQ memory, producing complete loss of kernel availability on affected mlx5 systems.