CVE-2024-50296 in Linux
Summary
by MITRE • 11/19/2024
In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when uninstalling driver
When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs:
[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
... [15278.131557][T50670] Call trace:
[15278.134686][T50670] klist_put+0x28/0x12c
[15278.138682][T50670] klist_del+0x14/0x20
[15278.142592][T50670] device_del+0xbc/0x3c0
[15278.146676][T50670] pci_remove_bus_device+0x84/0x120
[15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80
[15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c
[15278.162485][T50670] sriov_disable+0x50/0x11c
[15278.166829][T50670] pci_disable_sriov+0x24/0x30
[15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]
[15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge]
[15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230
[15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30
[15278.193848][T50670] invoke_syscall+0x50/0x11c
[15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164
[15278.203837][T50670] do_el0_svc+0x34/0xcc
[15278.207834][T50670] el0_svc+0x20/0x30
For details, see the following figure.
rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock();
In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/16/2025
The vulnerability described in CVE-2024-50296 affects the Linux kernel's implementation of the hns3 network driver, specifically within the hclge module responsible for managing the Huawei Intelligent NICs. This issue arises during the driver uninstallation process when virtual functions (VFs) are concurrently disabled, leading to a kernel crash due to improper resource management. The root cause stems from a race condition where the same function pci_disable_sriov() is invoked twice, resulting in attempts to release already-freed resources, which ultimately causes a null pointer dereference at virtual address 0x20.
The technical flaw manifests when the driver exit routine calls pci_disable_sriov() to disable SR-IOV functionality, while simultaneously, VF disabling operations invoke the same function. The first invocation properly processes the resource cleanup, but the second call, which occurs during driver removal, checks the num_VFs value that has already been reset to zero by the previous call. This leads to a situation where resources that have already been freed are attempted to be released again, causing a kernel NULL pointer dereference. The stack trace demonstrates the call sequence leading to the crash, starting from the module removal syscall through various kernel subsystems including device management and PCI bus handling, ultimately failing in the klist_put function which attempts to access a freed data structure.
This vulnerability directly relates to CWE-476, which describes NULL pointer dereference conditions, and impacts the kernel's stability and reliability in environments where network drivers are dynamically loaded and unloaded. The issue has significant operational implications for production systems using Huawei NICs, as it can lead to unexpected system crashes and service interruptions during normal driver maintenance operations. The vulnerability exposes a lack of proper synchronization mechanisms during concurrent driver and VF management operations, creating a path for system instability.
The mitigation strategy involves implementing proper locking mechanisms during driver removal to ensure that concurrent access to the num_VFs variable is properly synchronized. By acquiring the device_lock() during driver exit operations, similar to how sriov_numvfs_store() handles this scenario, the race condition is resolved. This aligns with ATT&CK technique T1489, which involves system denial of service through manipulation of system resources, and specifically addresses the kernel's resource management failure. The fix ensures that during driver removal, all VF-related operations are serialized, preventing the double release of resources that leads to the crash. This remediation approach follows standard kernel development practices for handling concurrent access to shared data structures and prevents unauthorized or unintended resource manipulation during driver lifecycle operations. The solution effectively protects against privilege escalation scenarios where an attacker might exploit this vulnerability to cause system instability or denial of service conditions.