CVE-2024-46746 in Linux
Summary
by MITRE • 09/18/2024
In the Linux kernel, the following vulnerability has been resolved:
HID: amd_sfh: free driver_data after destroying hid device
HID driver callbacks aren't called anymore once hid_destroy_device() has been called. Hence, hid driver_data should be freed only after the hid_destroy_device() function returned as driver_data is used in several callbacks.
I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling KASAN to debug memory allocation, I got this output:
[ 13.050438] ==================================================================
[ 13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]
[ 13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3
[ 13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479
[ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0
[ 13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024
[ 13.067860] Call Trace:
[ 13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8
[ 13.071486]
[ 13.071492] dump_stack_lvl+0x5d/0x80
[ 13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -> 0002)
[ 13.078296] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.082199] print_report+0x174/0x505
[ 13.085776] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 13.089367] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.093255] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.097464] kasan_report+0xc8/0x150
[ 13.101461] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.105802] amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.110303] amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]
[ 13.114879] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.119450] sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]
[ 13.124097] hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
[ 13.127404] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.131925] ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]
[ 13.136455] ? _raw_spin_lock_irqsave+0x96/0xf0
[ 13.140197] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 13.143602] ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]
[ 13.147234] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.150446] ? __devm_add_action+0x167/0x1d0
[ 13.155061] hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
[ 13.158581] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.161814] platform_probe+0xa2/0x150
[ 13.165029] really_probe+0x1e3/0x8a0
[ 13.168243] __driver_probe_device+0x18c/0x370
[ 13.171500] driver_probe_device+0x4a/0x120
[ 13.175000] __driver_attach+0x190/0x4a0
[ 13.178521] ? __pfx___driver_attach+0x10/0x10
[ 13.181771] bus_for_each_dev+0x106/0x180
[ 13.185033] ? __pfx__raw_spin_lock+0x10/0x10
[ 13.188229] ? __pfx_bus_for_each_dev+0x10/0x10
[ 13.191446] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.194382] bus_add_driver+0x29e/0x4d0
[ 13.197328] driver_register+0x1a5/0x360
[ 13.200283] ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]
[ 13.203362] do_one_initcall+0xa7/0x380
[ 13.206432] ? __pfx_do_one_initcall+0x10/0x10
[ 13.210175] ? srso_alias_return_thunk+0x5/0xfbef5
[ 13.213211] ? kasan_unpoison+0x44/0x70
[ 13.216688] do_init_module+0x238/0x750
[ 13.2196
---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 04/05/2026
The vulnerability described in CVE-2024-46746 relates to a memory management issue within the Linux kernel's HID (Human Interface Device) subsystem, specifically in the amd_sfh driver. This flaw manifests as a use-after-free error that occurs during the cleanup process of HID devices, leading to potential system instability and crashes. The root cause lies in the improper sequencing of memory deallocation relative to device destruction operations, which violates fundamental principles of safe memory management in kernel space.
The technical flaw arises from the incorrect timing of freeing driver data structures within the amd_sfh driver. When the hid_destroy_device() function is invoked, it signals that the HID device is being torn down, at which point all registered callbacks should cease execution. However, in the affected implementation, the driver_data structure containing critical device state information was being freed before the hid_destroy_device() function completed its execution. This sequence creates a window where callbacks, such as amd_sfh_get_report, may still attempt to access freed memory, resulting in the slab-use-after-free condition observed in the kernel stack trace.
The operational impact of this vulnerability is significant, particularly in systems utilizing AMD System Firmware Hub (SFH) controllers for HID device management. The crash pattern indicates that this issue is particularly prevalent during device initialization and enumeration phases, as evidenced by the call trace showing interactions with udev-worker processes and sensor hub drivers. The use of KASAN (Kernel Address Sanitizer) in the debugging process revealed that the freed memory address ff1ff88813152f408 was accessed during the amd_sfh_get_report callback, demonstrating how stale references can lead to immediate system failures.
This vulnerability aligns with CWE-415, which describes "Double Free" conditions in memory management, and more specifically with CWE-416, "Use After Free", which directly applies to the scenario where driver_data is accessed after being freed. The flaw also intersects with ATT&CK technique T1059.001, "Command and Scripting Interpreter: PowerShell", through the potential for exploitation via device enumeration and driver loading sequences, though the primary threat vector is system stability rather than direct command execution. The issue demonstrates a classic race condition in kernel driver cleanup routines where temporal ordering of operations is not properly enforced.
Mitigation strategies for CVE-2024-46746 involve ensuring proper sequencing of memory deallocation operations within the amd_sfh driver, specifically by deferring the freeing of driver_data until after hid_destroy_device() has fully completed its execution. This requires modifications to the driver's cleanup logic to ensure that all callback functions have returned before memory is released. The fix should be implemented as a patch to the Linux kernel, specifically targeting the amd_sfh driver module, and should be rolled out through standard kernel update mechanisms. System administrators should prioritize applying the relevant kernel security patches to affected systems, particularly those running kernel versions 6.10.0 and later where the vulnerability was observed. Additionally, monitoring for system crashes or instability during device enumeration phases can help identify systems that may be impacted by this vulnerability before a patch is applied.