CVE-2024-46717 in Linux
Summary
by MITRE • 09/18/2024
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: SHAMPO, Fix incorrect page release
Under the following conditions: 1) No skb created yet 2) header_size == 0 (no SHAMPO header) 3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page)
a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from header_index is released. This is wrong and it leads to SHAMPO header pages being released more than once.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/05/2026
The vulnerability identified as CVE-2024-46717 resides within the Linux kernel's mlx5e network driver, specifically affecting the SHAMPO (SHared Memory And Packet Offload) implementation used by Mellanox ConnectX network adapters. This issue manifests as a double-free condition that occurs during packet processing when handling SHAMPO headers, representing a critical memory management flaw that could potentially lead to system instability or exploitation. The vulnerability is categorized under CWE-415 as an improper handling of memory allocation and deallocation, specifically involving double-free conditions that can result in memory corruption and unpredictable system behavior.
The technical flaw occurs in the mlx5e_handle_rx_cqe_mpwrq_shampo() function where the driver incorrectly manages page references during packet reconstruction. When processing incoming packets under specific conditions, the kernel creates a new socket buffer (skb) using a regular data page rather than a SHAMPO header page, yet the code subsequently attempts to release what it believes to be a SHAMPO header page from the same index. This misidentification results in the same SHAMPO header page being released twice, causing memory corruption and potential security implications. The conditions that trigger this vulnerability include the absence of an skb creation, zero header size indicating no SHAMPO header processing is needed, and the specific calculation that identifies the last fragment of a SHAMPO header page within the page allocation scheme. This particular sequence of events violates proper resource management principles and can lead to heap corruption as outlined in the ATT&CK framework's resource exhaustion techniques.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially enable privilege escalation or denial of service attacks. When SHAMPO header pages are released multiple times, the kernel's memory management subsystem may experience undefined behavior, leading to system crashes, data corruption, or in worst-case scenarios, exploitation for privilege elevation. Network administrators and system operators face significant risk when running affected Linux kernel versions, particularly in high-throughput environments where Mellanox network adapters are heavily utilized. The vulnerability affects systems using Mellanox ConnectX series adapters with SHAMPO enabled, making it particularly relevant in data center and high-performance computing environments where these adapters are commonly deployed.
Mitigation strategies should prioritize immediate kernel updates to versions containing the patched code, as provided by the Linux kernel security team. Organizations should also implement monitoring for unusual system behavior or crashes that may indicate memory corruption, while maintaining regular patching schedules to address similar vulnerabilities. The fix implemented by the kernel developers involves proper page reference tracking and ensuring that only the correct page type is released at each stage of the packet processing pipeline, preventing the double-release condition that was causing the vulnerability. System administrators should verify that their network driver configurations are not inadvertently enabling SHAMPO features when the vulnerability conditions are met, and consider implementing network segmentation to limit the potential impact of such memory corruption issues.