CVE-2026-89741 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
Revert "media: v4l2-dev: fix error handling in __video_register_device()"
This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a.
The intentions of that patch were good, but it doesn't work.
The idea is that if device_register fails, you have to do a put_device to let the ref counter release resources.
However, the V4L2 API says that if video_register_device() fails, then you have to call video_device_release(), which kfree()s the video_device struct.
But the put_device() will already have freed the struct, so you end up in a double-free scenario.
There is not really a good way of fixing this without breaking video_register_device() into two parts, one that initializes everything, and one that does the actual device_register, and then converting all V4L2 drivers to this new model.
That is a massive job, and it is very unlikely that device_register will fail.
So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The Linux kernel recently addressed a critical error handling flaw within the Video4Linux2 subsystem by reverting commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. This revert resolves an issue introduced in __video_register_device, where incorrect reference counting logic led to a double-free vulnerability when device registration failed. The original patch attempted to correct resource management by ensuring that if the underlying device_register call fails, the driver would invoke put_device to decrement the reference count and allow proper cleanup of allocated resources. While this approach aligns with general kernel conventions for handling device object lifecycles, it fundamentally conflicts with the specific requirements of the V4L2 API architecture.
The core technical flaw stems from a mismatch between generic kernel device management practices and the specialized lifecycle model enforced by Video4Linux2 drivers. According to the V4L2 specification, if video_register_device returns an error code, the calling driver is responsible for invoking video_device_release. This function explicitly calls kfree on the video_device structure, thereby deallocating the memory associated with that object. However, because put_device was already called in the failure path of __video_register_device, it had previously decremented the reference count to zero and triggered the release callback, which also freed the same video_device struct. Consequently, when the driver subsequently executed its own cleanup routine by calling video_device_release, it attempted to free memory that had already been deallocated. This sequence results in a double-free condition, a severe class of vulnerability classified under CWE-415 Double Free.
The operational impact of this vulnerability is significant, as exploitation can lead to kernel panic or system instability due to heap corruption. A double-free allows an attacker with local access to potentially manipulate the kernel memory allocator’s internal structures, which may facilitate arbitrary code execution or denial of service conditions. Although the likelihood of device_register failing in typical hardware configurations is low, such failures can occur during driver initialization under specific edge cases involving resource exhaustion or hardware misconfiguration. The presence of this bug means that any system running affected kernels and attempting to register V4L2 devices could crash if registration fails for reasons other than standard permission errors.
Resolving this issue required a pragmatic decision to revert the problematic patch rather than implementing a comprehensive architectural fix. A robust solution would involve refactoring video_register_device into two distinct phases: one for initialization and another for actual device registration, thereby allowing drivers to handle cleanup correctly without relying on generic reference counting mechanisms that conflict with V4L2 semantics. However, such a refactor represents a massive engineering effort requiring changes across all V4L2 driver implementations. Given the low probability of failure in device_register and the high risk associated with introducing further complexity or breaking existing functionality, the maintainers opted for stability over theoretical correctness. The revert accepts a minor memory leak as a trade-off to eliminate the critical double-free vulnerability, ensuring that systems remain stable even if resources are not perfectly reclaimed during rare error paths.
From a mitigation perspective, administrators should ensure their Linux kernels are updated to include this revert patch. This update restores the previous behavior where failed registrations result in a small memory leak rather than a crash. While memory leaks can degrade system performance over long uptimes, they do not pose an immediate security risk or stability threat comparable to double-free vulnerabilities. Future development efforts may focus on gradually refactoring V4L2 drivers to adopt safer initialization patterns that decouple device registration from reference counting management, thereby aligning the subsystem more closely with standard kernel practices without compromising reliability in error scenarios. This incident highlights the importance of rigorous testing for edge cases in driver code and the value of reverting changes that introduce severe stability risks even if their intent was to improve resource hygiene.