CVE-2024-43900

media: xc2028: avoid use-after-free in load_firmware_cb()

HIGH
7.8
CVSS Score
Published: August 26, 2024 at 10:10 AM UTC
Updated: June 17, 2026 at 07:51 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 6.1.1053.6 ≤ v < 6.1.1053.6 ≤ v < 6.10.53.6 ≤ v < 6.113.6 ≤ v < 6.6.466.2 ≤ v < 6.6.466.7 ≤ v < 6.10.53.661a96113de51e1f8f43ac98cbeadb54e60045905
Vendor states this is fixed in 208deb6d8c3cb8c3acb1f41eb31cf68ea08726d5 (fixed)
Vendor states this is fixed in 68594cec291ff9523b9feb3f43fd853dcddd1f60 (fixed)
Vendor states this is fixed in 850304152d367f104d21c77cfbcc05806504218b (fixed)
Vendor states this is fixed in ef517bdfc01818419f7bd426969a0c86b14f3e0e (fixed)
Vendor states this is fixed in 3.6 (unaffected)
Vendor states this is fixed in 6.1.105 (unaffected)
Vendor states this is fixed in 6.10.5 (unaffected)
Vendor states this is fixed in 6.11 (unaffected)
Vendor states this is fixed in 6.6.46 (unaffected)

References (5)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/208deb6d8c3cb8c3acb1f41eb31cf68ea08726d5
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/68594cec291ff9523b9feb3f43fd853dcddd1f60
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/850304152d367f104d21c77cfbcc05806504218b
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/ef517bdfc01818419f7bd426969a0c86b14f3e0e
Source: af854a3a-2127-422b-91ae-364da2661108
https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-416

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card