CVE-2026-72482 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
gpib: fix double decrement of descriptor_busy in command_ioctl()
commit d1857f8296dc ("gpib: fix use-after-free in IO ioctl handlers") introduced a descriptor_busy reference counter to pin struct gpib_descriptor across IO ioctl operations. In command_ioctl(), the error path inside the loop decrements descriptor_busy and breaks, but execution then falls through to the unconditional decrement after the loop, underflowing the counter to -1.
This re-enables the use-after-free that the original fix was meant to prevent: a concurrent close_dev_ioctl() sees descriptor_busy == 0 on an actively-used descriptor and frees it.
Remove the early decrement from the error path. The post-loop decrement already handles all exit paths, matching the correct pattern used in read_ioctl() and write_ioctl().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides within the Linux kernel's GPIB (General Purpose Interface Bus) subsystem where a critical race condition exists in the command_ioctl() function that undermines memory safety mechanisms. This issue stems from an improper reference counting implementation that was initially introduced to address use-after-free conditions in IO ioctl handlers. The original commit d1857f8296dc implemented a descriptor_busy reference counter designed to prevent premature freeing of struct gpib_descriptor structures during active IO operations. However, the subsequent implementation contains a logical flaw in error handling paths that creates an unintended double decrement scenario.
The technical flaw manifests when command_ioctl() processes commands within a loop structure where error conditions trigger an early decrement of the descriptor_busy counter followed by an unconditional decrement after the loop completes. This dual decrement operation causes the reference counter to underflow from its intended positive value to -1, effectively breaking the memory protection mechanism that was designed to prevent concurrent access to freed resources. The underflow condition creates a window where another thread executing close_dev_ioctl() can observe descriptor_busy equal to zero on an actively referenced descriptor and proceed with freeing the memory structure while other operations are still in progress.
This vulnerability directly impacts system stability and security by re-enabling the very use-after-free scenario that the original fix was intended to prevent. When the reference counter underflows, the kernel's memory management system loses track of which descriptors remain actively in use versus those that can be safely freed. The attack surface becomes particularly concerning in multi-threaded environments where concurrent access patterns increase the likelihood of race conditions between IO operations and device closure events. The flaw creates a potential avenue for memory corruption that could lead to privilege escalation or system crashes, as the kernel cannot reliably determine descriptor lifecycle states.
The vulnerability demonstrates a clear deviation from established patterns within the same codebase, particularly when compared to how read_ioctl() and write_ioctl() functions properly handle their reference counting logic. This inconsistency highlights poor code maintenance practices where similar functionality is implemented with different error handling approaches, creating unexpected behaviors. The fix requires removing the early decrement from the error path while maintaining the post-loop decrement that correctly handles all execution paths. This approach aligns with established security patterns and maintains proper reference counting semantics throughout the kernel subsystem.
From a cybersecurity perspective, this vulnerability represents a classic example of how defensive programming measures can introduce new flaws when not carefully implemented across all code paths. The issue falls under CWE-129, which addresses insufficient checking of buffer bounds, and potentially CWE-416, concerning use-after-free conditions. It also maps to ATT&CK technique T1068, which involves exploiting local system permissions through privilege escalation vectors. The vulnerability underscores the critical importance of thorough code review processes, particularly for memory management operations in kernel space where improper handling can compromise entire system security models.
The operational impact extends beyond immediate memory safety concerns to include potential denial-of-service conditions and data integrity issues in systems relying on GPIB communication protocols. Organizations using Linux kernels with affected versions should prioritize patching to prevent exploitation of this reference counting flaw that could allow attackers to manipulate kernel memory structures or cause system instability. The vulnerability serves as a reminder of the complexity inherent in kernel-level programming where seemingly simple fixes can have cascading effects on system reliability and security posture, emphasizing the need for comprehensive testing across all execution paths in security-critical code sections.