CVE-2026-89741

HIGHCVSS 7.8/10EPSS 0.16%

Last modified

CVE-2026-89741 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. 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.. EPSS estimates a 0.16% chance of exploitation in the next 30 days.

Description

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.

Metrics

EPSS Probability
0.16%

5.8th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= e5c8e62ae551e0ad2e15412aa0c57c2856d59677, < 8b998c171ed875e402e1fd1c5cd619e4ca05e9c1; >= 8b451a9a46f2bfc510e6d5c2492df91647586184, < 3de14b4f681a1b3c6d375d98d9d37a55ebb85349; >= b6be1f5633eae200af2527e9eeb7f51be5739b0f, < 8027f82c0f5474ed72448e160ee9778051fa1f49; >= ae7b143e05b36fc69d6571751855946cc45064c6, < 2ac009a65d2385e9f0799eaf9d9694a29153a161; >= 2429bb9fad88c8fa84c4956b0a21cf5afe5e92b7, < 712ca1cf756de2557a116e0df55791bac0c9f99e; >= 2a934fdb01db6458288fc9386d3d8ceba6dd551a, < aad08b5f67d2a8116e1a00bce2611c1513b10bce; >= 2a934fdb01db6458288fc9386d3d8ceba6dd551a, < ce792b94e03882108019ba996c1a7c4d4e09be2c; >= 2a934fdb01db6458288fc9386d3d8ceba6dd551a, < e7600f5cee5de14065f950807931d6e6d40fb2d7; ee141706e701356dda41c6fed9ee18bf427c28e3; 4451412739ed33a49b34624299394ee575116d0c; >= 5.10.239, < 5.10.270; >= 5.15.186, < 5.15.221; >= 6.1.142, < 6.1.188; >= 6.6.95, < 6.6.157; >= 6.12.35, < 6.12.109; >= 5.4.295, < 5.5; >= 6.15.4, < 6.16
LinuxLinux6.16

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-89741?
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.
How severe is CVE-2026-89741?
CVE-2026-89741 has a CVSS score of 7.8/10 (HIGH severity). The EPSS model estimates a 0.16% probability of exploitation in the next 30 days.
How do I fix CVE-2026-89741?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-89741?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST