CVE-2026-74717 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: fw_tracer, return NULL on create error
Tracer creation can fail by returning either NULL or ERR_PTR. The return value is stored without a check on the device, and users treat ERR_PTR and NULL the same way. This also causes a crash in the core dump logic, which is missing the ERR_PTR check and ends up dereferencing it, as shown in the trace below.
Switch tracer creation to return NULL on failure only, so callers only need a single NULL check.
Internal error: Oops: 0000000096000006 [#1] SMP
Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none) Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core]
pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core]
lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core]
sp : ffff800081cf3c40 x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000 x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05 x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000 x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0 x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650 x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8 x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e Call trace: mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P)
mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core]
devlink_health_do_dump+0x9c/0x160 devlink_health_report+0x1c0/0x288 mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core]
process_one_work+0x15c/0x3d8 worker_thread+0x18c/0x320 kthread+0x148/0x228 ret_from_fork+0x10/0x20 Code: b9400000 5ac00800 7a401800 540003ca (3940a260) ---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x000000,00078031,75fce5a1,35fffe67 Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel driver for Mellanox ConnectX network adapters contains a critical logic error within the firmware tracer subsystem that leads to system instability and potential denial of service. The vulnerability stems from an inconsistent handling of return values during the creation of the firmware tracer object. Specifically, the function responsible for creating this tracer can fail by returning either a NULL pointer or an ERR_PTR value depending on the specific failure condition encountered. However, subsequent code paths in the driver do not distinguish between these two distinct error representations. Instead, they treat both scenarios identically as successful allocations that require no further validation before use. This oversight violates standard kernel programming practices where callers are expected to check for NULL pointers or explicitly handle ERR_PTR values using helper functions like IS_ERR_OR_NULL.
The operational impact of this flaw is severe, manifesting primarily as a kernel panic and system crash under specific failure conditions. When the tracer creation fails with an ERR_PTR value rather than NULL, the calling code proceeds assuming valid memory has been allocated. This erroneous assumption becomes critical when the core dump logic attempts to utilize the tracer object during health reporting events. Because the pointer is actually an encoded error code disguised as a memory address, dereferencing it results in an invalid memory access. The provided trace indicates that this occurs within the mlx5_fw_tracer_trigger_core_dump_general function, which is invoked via devlink_health_report mechanisms triggered by firmware errors. Consequently, instead of gracefully handling the failure or reporting the issue safely, the kernel encounters a fatal exception, leading to a complete system halt and loss of availability for any services relying on this hardware.
From a vulnerability classification perspective, this defect aligns with CWE-252, Unchecked Return Value, as the code fails to verify the success status of a critical function call before proceeding. Furthermore, it relates closely to CWE-476, NULL Pointer Dereference, although in this specific instance, the dereferenced value is technically an ERR_PTR rather than a true null address; however, the effect on system stability and the nature of the memory access violation are analogous. In terms of attack vectors, while this vulnerability does not directly allow for arbitrary code execution or privilege escalation by an external attacker, it can be leveraged to cause a Denial of Service condition. An adversary with local access who can trigger firmware error conditions might induce the tracer creation failure path, thereby crashing the host system and disrupting network connectivity and other critical operations dependent on the kernel's stability.
The resolution involves refactoring the mlx5_fw_tracer_create function to consistently return NULL upon any type of failure, eliminating the ambiguity between ERR_PTR and NULL returns. By standardizing the error reporting mechanism, all callers are required only to perform a single null check before using the returned pointer. This simplification reduces code complexity and eliminates the possibility of misinterpreting an error state as a valid object reference. To mitigate similar issues in other parts of the driver or future development cycles, developers should enforce strict adherence to kernel conventions regarding return value checking. Utilizing standard macros such as IS_ERR_OR_NULL can provide robust protection against these types of logic errors. Additionally, implementing static analysis tools that flag inconsistent error handling patterns within the mlx5 subsystem would help prevent regression and ensure long-term code quality and system resilience.