CVE-2022-49685 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
iio: trigger: sysfs: fix use-after-free on remove
Ensure that the irq_work has completed before the trigger is freed.
================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25
Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt
Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write
Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write
==================================================================
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 03/25/2025
This vulnerability exists in the Linux kernel's Industrial I/O (IIO) subsystem within the trigger sysfs interface implementation. The issue manifests as a use-after-free condition that occurs during the removal of IIO triggers through sysfs operations. The vulnerability specifically affects the irq_work mechanism that handles interrupt processing for IIO triggers, creating a race condition between the completion of asynchronous work and the deallocation of trigger resources. The kernel's memory safety checker (KASAN) detected this issue when a read operation attempted to access memory at address 0x64702248 that had already been freed by the iio_sysfs_trig_remove function. The call trace shows the sequence where irq_work_run_list attempts to process work items after the trigger structure has been deallocated, leading to memory corruption and potential system instability.
The technical flaw stems from improper synchronization between the asynchronous irq_work processing and the trigger removal lifecycle. When an IIO trigger is removed through sysfs, the kernel frees the trigger structure immediately without ensuring that all pending irq_work operations have completed. This creates a window where interrupt handling code can attempt to access freed memory structures, violating fundamental memory safety principles. The vulnerability is classified under CWE-416 as Use After Free, which represents a critical security flaw where program code attempts to access memory after it has been freed by the system. This type of vulnerability can lead to arbitrary code execution, data corruption, or system crashes when the freed memory is reallocated and accessed incorrectly.
The operational impact of this vulnerability extends beyond simple memory corruption, as it affects the stability and reliability of industrial I/O systems that depend on proper trigger management. Systems using IIO triggers for sensor data acquisition, event handling, or timing synchronization could experience unexpected behavior when triggers are removed, potentially leading to data loss or system crashes. The vulnerability affects kernel versions where the IIO subsystem processes trigger removal through sysfs interfaces, particularly impacting embedded systems and industrial automation platforms that rely heavily on IIO functionality. Attackers could potentially exploit this vulnerability to cause denial of service conditions or escalate privileges, especially in environments where IIO triggers are frequently created and destroyed during normal operation.
Mitigation strategies should focus on ensuring proper synchronization between trigger removal and irq_work completion. The recommended approach involves implementing a mechanism to wait for pending irq_work operations to complete before freeing trigger resources, similar to the approach used in other kernel subsystems for handling asynchronous work cleanup. System administrators should ensure their kernels are updated to versions containing the fix, which typically involves modifying the iio_sysfs_trig_remove function to include proper completion waiting for irq_work operations. Additionally, monitoring systems should be implemented to detect and alert on potential memory corruption events, particularly in industrial environments where IIO triggers are heavily utilized. Organizations should also consider implementing kernel lockdown mechanisms and access controls to limit exposure to potential exploitation of such vulnerabilities in the IIO subsystem. The fix aligns with ATT&CK technique T1068 by addressing privilege escalation through kernel memory corruption vulnerabilities, and follows security best practices outlined in the Linux kernel security documentation for proper resource management and synchronization.