CVE-2022-50002 in Linux
Summary
by MITRE • 06/18/2025
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READY
Only set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered. Doing so guarantees that both ldev->pf[MLX5_LAG_P0].dev and
ldev->pf[MLX5_LAG_P1].dev have valid pointers when
MLX5_LAG_FLAG_NDEVS_READY is set.
The core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY and clearing it. Setting it is done wrongly when both ldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev are set;
clearing it is done right when either of ldev->pf[i].netdev is cleared.
Consider the following scenario: 1. PF0 loads and sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer
2. PF1 loads and sets both ldev->pf[MLX5_LAG_P1].dev and
ldev->pf[MLX5_LAG_P1].netdev with valid pointers. This results in
MLX5_LAG_FLAG_NDEVS_READY is set. 3. PF0 is unloaded before setting dev->pf[MLX5_LAG_P0].netdev.
MLX5_LAG_FLAG_NDEVS_READY remains set.
Further execution of mlx5_do_bond() will result in null pointer dereference when calling mlx5_lag_is_multipath()
This patch fixes the following call trace actually encountered:
[ 1293.475195] BUG: kernel NULL pointer dereference, address: 00000000000009a8
[ 1293.478756] #PF: supervisor read access in kernel mode
[ 1293.481320] #PF: error_code(0x0000) - not-present page
[ 1293.483686] PGD 0 P4D 0
[ 1293.484434] Oops: 0000 [#1] SMP PTI
[ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 Not tainted 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1
[ 1293.488039] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 1293.490836] Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core]
[ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core]
[ 1293.494044] Code: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8
[ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202
[ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000
[ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000
[ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c
[ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0
[ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858
[ 1293.508753] FS: 0000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000
[ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0
[ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/30/2025
The vulnerability CVE-2022-50002 resides within the Linux kernel's mlx5 driver, specifically in the handling of Link Aggregation Group (LAG) functionality. This issue stems from an asymmetric logic implementation concerning the MLX5_LAG_FLAG_NDEVS_READY flag, which is critical for managing multi-path network device operations. The flaw manifests when both physical functions (PF0 and PF1) of a Mellanox network adapter are loaded and unloaded in specific sequences, creating a race condition that results in improper flag state management. The vulnerability is classified under CWE-471, which denotes the assignment of an incorrect value to a variable, and aligns with ATT&CK technique T1059.001 for command and scripting interpreter, as it involves kernel-level code execution paths that can be leveraged for system instability.
The technical flaw occurs due to inconsistent handling of the MLX5_LAG_FLAG_NDEVS_READY flag during device registration and unregistration phases. When PF0 loads first, it sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer, but the flag is not yet set. When PF1 subsequently loads, it sets both ldev->pf[MLX5_LAG_P1].dev and ldev->pf[MLX5_LAG_P1].netdev with valid pointers, triggering the incorrect setting of MLX5_LAG_FLAG_NDEVS_READY. However, when PF0 is unloaded without properly clearing ldev->pf[MLX5_LAG_P0].netdev, the flag remains set even though one of the required device pointers has been invalidated. This asymmetric behavior creates a scenario where the flag indicates readiness for both devices while only one device is actually valid, leading to a null pointer dereference in subsequent mlx5_do_bond() operations.
The operational impact of this vulnerability is severe, as it can result in kernel panics and system crashes, particularly during network device reconfiguration or hot-plugging scenarios. The null pointer dereference occurs at the mlx5_lag_is_multipath function, which is part of the core network bonding logic that determines whether the system should operate in multipath mode. This condition directly violates the kernel's memory safety guarantees and can be exploited to cause denial of service attacks against systems running affected kernel versions. The vulnerability affects systems using Mellanox ConnectX series adapters in configurations that employ LAG functionality, making it particularly relevant for high-performance computing and data center environments where network reliability is paramount.
Mitigation strategies for CVE-2022-50002 involve updating to kernel versions that contain the fixed implementation, where the logic has been corrected to only set MLX5_LAG_FLAG_NDEVS_READY when both netdevices are properly registered and have valid pointers. The fix ensures that the flag is cleared appropriately when either of the device pointers becomes invalid, preventing the scenario where one device pointer is cleared while the other remains valid, yet the flag continues to indicate readiness. Administrators should also implement monitoring for kernel oops messages and system stability issues that may indicate the presence of this vulnerability in unpatched systems. Additionally, the vulnerability highlights the importance of proper synchronization mechanisms in kernel drivers and adherence to best practices for flag management in concurrent environments, which aligns with ATT&CK technique T1547.001 for registry run keys and T1562.001 for_impact for system resource hijacking.