CVE-2024-43900 in Linux
Summary
by MITRE • 08/26/2024
In the Linux kernel, the following vulnerability has been resolved:
media: xc2028: avoid use-after-free in load_firmware_cb()
syzkaller reported use-after-free in load_firmware_cb() [1].
The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free.
The process is as follows:
task-6504 worker_thread tuner_probe <= alloc dvb_frontend [2]
... request_firmware_nowait <= create a worker ... tuner_remove <= free dvb_frontend ... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freed
To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is null, report a warning and just return.
[1]:
================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504
Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20
Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770
Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770
The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================
[2]
Actually, it is allocated for struct tuner, and dvb_frontend is inside.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/28/2024
The vulnerability described in CVE-2024-43900 affects the Linux kernel's media subsystem, specifically within the xc2028 tuner driver. This issue manifests as a use-after-free condition that occurs during firmware loading operations, creating a potential security risk that could be exploited to cause system instability or unauthorized access. The flaw arises from improper synchronization between device initialization and asynchronous firmware loading mechanisms. When a tuner device is probed and subsequently removed before firmware loading completes, the kernel attempts to access freed memory, leading to a use-after-free error that can be detected by kernel address sanitizer (KASAN).
The technical root cause involves the interaction between multiple kernel components during device lifecycle management. During tuner_probe(), a struct tuner is allocated which contains a dvb_frontend member. The device initialization process then spawns a worker thread to handle firmware loading via request_firmware_nowait(). However, if the device removal process occurs before firmware loading completes, the dvb_frontend structure gets freed in tuner_remove(), while the worker thread continues execution and attempts to access the freed structure in load_firmware_cb(). This race condition creates a classic use-after-free scenario that violates memory safety principles and can result in kernel memory corruption. The vulnerability specifically targets the Linux kernel's media subsystem and is categorized under CWE-416, which addresses use-after-free conditions. The ATT&CK framework would classify this under T1059.001 (Command and Scripting Interpreter: PowerShell) as a system-level exploit, though more accurately it represents a kernel-level memory corruption vulnerability that could be leveraged for privilege escalation.
The operational impact of this vulnerability extends beyond simple system crashes, potentially allowing for arbitrary code execution or denial of service conditions within the kernel space. The flaw affects systems utilizing the em28xx driver family, particularly those with xc2028 tuner devices, making it relevant to various multimedia and broadcast receiver applications. The vulnerability's exploitation requires specific timing conditions and may be difficult to reproduce in controlled environments, yet it represents a serious security concern for kernel developers and system administrators. The fix implemented addresses this by adding a null check in load_firmware_cb() to verify that the dvb_frontend pointer remains valid before accessing it, preventing the use-after-free scenario. This mitigation aligns with standard kernel security practices for handling asynchronous operations and memory lifecycle management, ensuring that kernel subsystems properly validate object references before accessing them. The solution demonstrates proper defensive programming techniques and follows the kernel's established patterns for handling potentially freed objects in asynchronous contexts, thereby reducing the attack surface and improving overall system stability.