CVE-2022-48796 in Linux
Summary
by MITRE • 07/16/2024
In the Linux kernel, the following vulnerability has been resolved:
iommu: Fix potential use-after-free during probe
Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free.
BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153
Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78 __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228 __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18
Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu]
arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]
platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu]
do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180
Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu]
arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]
platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu]
do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180
Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 01/11/2025
The vulnerability described in CVE-2022-48796 represents a critical use-after-free condition within the Linux kernel's IOMMU subsystem, specifically affecting device probe operations on ARM-based systems. This flaw manifests when a device probe fails and the kernel attempts to free the device's IOMMU structure while another parallel process is simultaneously attempting to access the same memory location. The issue is particularly significant because it occurs during the device initialization phase, where the kernel is setting up IOMMU mappings for hardware devices, making it a potential attack vector for privilege escalation or system instability.
The technical root cause stems from a race condition between two kernel threads executing concurrently during device probe failure scenarios. When a device probe fails, the kernel invokes the dev_iommu_free function to release memory allocated for the device's IOMMU structure. However, this cleanup process does not properly synchronize with the deferred_probe_work_func workqueue which runs in parallel and attempts to access the freed memory location through the of_iommu_configure function. The KASAN (Kernel Address Sanitizer) report clearly demonstrates that the memory access occurs at address 0xffffffff87a2f1acb8, with the read operation of size 8 triggering the use-after-free error. This pattern aligns with CWE-416, which defines use-after-free vulnerabilities as conditions where a program continues to use a pointer after the memory it points to has been freed, creating a potential for memory corruption or information disclosure.
The operational impact of this vulnerability extends beyond simple system crashes, as it can lead to unpredictable behavior in kernel memory management and potentially enable attackers to exploit the race condition for privilege escalation. The vulnerability specifically affects ARM SMMU (System Memory Management Unit) drivers, which are commonly used in mobile and embedded systems where IOMMU functionality is critical for memory protection. The attack surface is particularly concerning in environments where devices are dynamically probed and configured, as the race condition can be triggered during normal system operation, not just in controlled exploit scenarios. This aligns with ATT&CK technique T1068, which involves the exploitation of privilege escalation vulnerabilities through kernel-level memory corruption.
The fix implemented addresses the core synchronization issue by ensuring that dev->iommu is set to NULL before the dev_iommu structure is freed in the dev_iommu_free function. This simple but critical change prevents the parallel workqueue from accessing freed memory by ensuring proper ordering of memory operations. The solution follows established kernel development practices for handling race conditions in memory management, where explicit NULL assignment before deallocation prevents use-after-free conditions. This mitigation directly addresses the root cause rather than merely masking the symptoms, ensuring that the kernel's IOMMU subsystem maintains memory safety during device probe failure scenarios. The fix is consistent with kernel security best practices and represents a minimal change that preserves existing functionality while eliminating the race condition that led to the vulnerability.