CVE-2024-58054 in Linux
Summary
by MITRE • 03/06/2025
In the Linux kernel, the following vulnerability has been resolved:
staging: media: max96712: fix kernel oops when removing module
The following kernel oops is thrown when trying to remove the max96712 module:
Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2 imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse [last unloaded: imx8_isi]
CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP
Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr : v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: led_put+0x1c/0x40 v4l2_subdev_put_privacy_led+0x48/0x58 v4l2_async_unregister_subdev+0x2c/0x1a4 max96712_remove+0x1c/0x38 [max96712]
i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x4c/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 max96712_i2c_driver_exit+0x18/0x1d0 [max96712]
__arm64_sys_delete_module+0x1a4/0x290 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]---
This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2_async_unregister_subdev(), leading to a crash.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 01/23/2026
The vulnerability described in CVE-2024-58054 affects the Linux kernel's media staging driver for the max96712 device, specifically during module removal operations. This issue manifests as a kernel oops, indicating a critical memory access violation that can lead to system instability or potential exploitation. The problem occurs when attempting to remove the max96712 module, resulting in a data abort exception at virtual address 0x00007375746174db, which corresponds to a translation fault in the memory management subsystem. The error code ESR = 0x0000000096000004 indicates a synchronous data abort with level 0 translation fault, suggesting that the kernel attempted to access unmapped memory.
The root cause of this vulnerability lies in improper pointer management within the v4l2_i2c_subdev_init() function. During module initialization, i2c_set_clientdata() is invoked multiple times, causing the client data pointer to be overwritten. Specifically, the client data is set to point to the subdevice structure sd instead of the private data structure priv. This incorrect pointer assignment propagates through the module lifecycle and becomes critical during removal operations. When the max96712_remove() function executes, it passes the wrong pointer to v4l2_async_unregister_subdev(), resulting in a dereference of invalid memory addresses. The call trace shows the execution path leading to led_put(), which attempts to access memory at an invalid address, ultimately causing the kernel oops and system crash.
This vulnerability represents a classic case of improper memory management and pointer handling that can be classified under CWE-476, Null Pointer Dereference, and CWE-121, Stack-based Buffer Overflow, though the specific manifestation is more aligned with improper pointer arithmetic and memory corruption during module lifecycle operations. The issue is particularly concerning in embedded systems and automotive environments where the i.MX95 platform is commonly deployed, as it can lead to complete system failures during driver unloading operations. The vulnerability affects systems running Linux kernel versions including 6.12.0-rc6 and potentially earlier versions where the max96712 driver is present.
From an operational security perspective, this vulnerability presents a significant risk during system maintenance operations, particularly when drivers need to be dynamically removed or updated. The attack surface is limited to systems utilizing the max96712 media device driver, but the impact is severe as it can cause system crashes or hangs during normal module removal procedures. The vulnerability aligns with ATT&CK technique T1059.001 for command and scripting interpreter, as it can be triggered through standard module removal commands like rmmod. The fix involves correcting the pointer assignment in the initialization function to ensure that client data points to the correct private structure rather than the subdevice structure. System administrators should ensure that all affected kernels are updated with patches that properly manage the client data pointers during driver initialization and removal operations, particularly in production environments where dynamic driver loading and unloading occurs regularly.