CVE-2026-89741: Revert "media: v4l2-dev: fix error handling in __video_register_device()"
In the Linux kernel, the following vulnerability has been resolved:
Revert "media: v4l2-dev: fix error handling in videoregisterdevice()"
This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a.
The intentions of that patch were good, but it doesn't work.
The idea is that if deviceregister fails, you have to do a putdevice to let the ref counter release resources.
However, the V4L2 API says that if videoregisterdevice() fails, then you have to call videodevicerelease(), which kfree()s the videodevice struct.
But the putdevice() 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 videoregisterdevice() into two parts, one that initializes everything, and one that does the actual deviceregister, and then converting all V4L2 drivers to this new model.
That is a massive job, and it is very unlikely that deviceregister 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 2a934fdb01db6458288fc9386d3d8ceba6dd551a - Compensating control
If video_register_device() fails, call video_device_release(), which kfree()s the video_device, to avoid a double-free scenario.
Event History
Frequently Asked Questions
What condition is required to trigger the double-free?
A V4L2 driver must call video_register_device(), device_register() must fail, and the driver must then follow the V4L2 API requirement to call video_device_release(). The earlier error-handling change calls put_device() after the registration failure, which may already free the video_device structure before video_device_release() frees it again.
What is the safe mitigation if the corrected change is not yet available?
Revert commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a. The revert intentionally accepts a small memory leak when device_register() fails rather than risking a double-free.
How can I determine whether a kernel source tree contains the affected behavior?
Check whether it includes commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a and does not include the revert. The provided stable references identify commits that revert the problematic change.