CVE-2026-98677 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad_sigma_delta: fix use-after-free on unbind
ad_sd_buffer_postenable() allocates sigma_delta->samples_buf with devm_krealloc() at runtime, so its devres entry sits after all probe-time entries of the driver. devm resources are released in reverse allocation order, which means unbind frees samples_buf before iio_device_unregister() disables the buffers and detaches the trigger pollfunc. The data ready IRQ is still enabled at that point, so ad_sd_trigger_handler() can still run and memcpy() incoming samples into the freed samples_buf.
Fix this by preallocating the buffer in devm_ad_sd_setup_buffer_and_trigger(), before the triggered buffer and the IRQ are set up, so it is freed only after iio_device_unregister() has drained the trigger handler via free_irq(). Size it for the worst case of all sequencer slots being active; ad_sd_validate_scan_mask() already caps the number of active channels at num_slots.
This issue was found by an in-house static analysis tool.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel vulnerability identified as a use-after-free condition within the industrial I/O subsystem specifically affects the ad_sigma_delta ADC driver. This flaw arises from a critical ordering error during device unbind operations, where memory deallocation occurs prematurely relative to the termination of hardware interrupt handlers. The root cause lies in how dynamic memory resources are managed using the devres framework. When the driver is bound, it allocates a buffer for sample data via devm_krealloc within the ad_sd_buffer_postenable function. Because this allocation happens at runtime rather than during the initial probe phase, its corresponding device resource management entry is registered after all probe-time entries. The Linux kernel's devres subsystem guarantees that resources are released in reverse order of their registration to ensure proper cleanup dependencies. Consequently, when the driver is unbound and devices are detached, the samples buffer allocated by ad_sd_buffer_postenable is freed before iio_device_unregister completes its full teardown sequence.
The operational impact of this vulnerability is severe, leading to potential kernel crashes or arbitrary code execution through memory corruption. The critical timing issue occurs because the data ready interrupt request remains enabled while the unbind process proceeds. Specifically, the trigger poll function and associated hardware interrupts are not fully disabled until iio_device_unregister finishes its work. However, since the buffer was freed earlier in the reverse cleanup order, any subsequent invocation of the ad_sd_trigger_handler by the hardware will attempt to copy incoming sample data into a memory region that has already been returned to the system allocator. This constitutes a classic use-after-free scenario where the kernel writes to invalid or potentially reallocated memory space. Such an event can corrupt adjacent heap structures, lead to information disclosure if the freed memory is reused for sensitive data, or cause a denial of service through a general protection fault when accessing unmapped pages.
From a vulnerability classification perspective, this issue aligns with CWE-416, Use After Free, which describes situations where software continues to use a pointer after it has been freed, leading to undefined behavior and potential security breaches. In the context of the MITRE ATT&CK framework for enterprise cybersecurity, this type of kernel-level memory corruption is often associated with techniques that facilitate privilege escalation or system compromise by exploiting race conditions in resource management. The vulnerability highlights the complexity of managing dynamic resources within device drivers where lifecycle states must be strictly synchronized across hardware interrupts and software unbinding routines. Static analysis tools played a crucial role in identifying this logical flaw, demonstrating their value in detecting subtle concurrency and ordering issues that are difficult to catch through manual code review alone.
The resolution involves restructuring the buffer allocation logic to ensure proper lifetime management relative to interrupt handling. Instead of allocating the samples buffer dynamically during post-enable operations, the fix mandates preallocation within devm_ad_sd_setup_buffer_and_trigger. This function is called before the triggered buffer and interrupts are set up, ensuring that the memory resource entry for the buffer appears earlier in the registration list than those associated with IRQs and trigger handlers. As a result, when unbinding occurs, the reverse order of deallocation guarantees that iio_device_unregister will first disable buffers and detach poll functions via free_irq, effectively draining any pending or ongoing interrupt handler executions. Only after these safety mechanisms are fully deactivated is the preallocated buffer freed. This approach also optimizes memory usage by sizing the buffer for the worst-case scenario where all sequencer slots are active, a constraint already enforced by ad_sd_validate_scan_mask which caps the number of active channels at num_slots.
Mitigation strategies for this vulnerability primarily involve applying the upstream kernel patch that corrects the allocation order in the ad_sigma_delta driver system administrators and distribution maintainers should prioritize updating to patched versions of the Linux kernel where this fix is integrated. For environments unable to immediately update, monitoring logs for general protection faults or memory corruption errors related to IIO ADC drivers may provide early indicators of exploitation attempts. Furthermore, developers working on similar device drivers should adopt strict adherence to resource lifecycle rules, ensuring that dynamic allocations intended for interrupt handlers are registered before the interrupts themselves are enabled. This ensures that cleanup routines naturally protect against race conditions by maintaining a dependency chain where memory is released only after all associated hardware interactions have ceased.