Linux Kernel up to 6.12.108/6.18.49/7.2.3 V4L2 __video_register_device double free

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 9.5 | $5k-$25k | 0.00+ |
Summary
A vulnerability was found in Linux Kernel up to 6.12.108/6.18.49/7.2.3. It has been classified as very critical. This affects the function __video_register_device of the component V4L2. The manipulation leads to double free.
This vulnerability is referenced as CVE-2026-89741. Remote exploitation of the attack is possible. No exploit is available.
Upgrading the affected component is recommended.
Details
A vulnerability was found in Linux Kernel up to 6.12.108/6.18.49/7.2.3 and classified as very critical. This issue affects the function __video_register_device of the component V4L2. The manipulation with an unknown input leads to a double free vulnerability. Using CWE to declare the problem leads to CWE-415. The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations. Impacted is confidentiality, integrity, and availability. The summary by CVE is:
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.
It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-89741 since 09/11/2026. The exploitation is known to be easy. The attack may be initiated remotely. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 09/11/2026).
Upgrading to version 6.12.109, 6.18.50, 7.2.4 or 7.3-rc1 eliminates this vulnerability. Applying the patch 712ca1cf756de2557a116e0df55791bac0c9f99e/aad08b5f67d2a8116e1a00bce2611c1513b10bce/ce792b94e03882108019ba996c1a7c4d4e09be2c/e7600f5cee5de14065f950807931d6e6d40fb2d7 is able to eliminate this problem. The best possible mitigation is suggested to be upgrading to the latest version.
Be aware that VulDB is the high quality source for vulnerability data.
Product
Type
Vendor
Name
Version
- 6.12.108
- 6.18.0
- 6.18.1
- 6.18.2
- 6.18.3
- 6.18.4
- 6.18.5
- 6.18.6
- 6.18.7
- 6.18.8
- 6.18.9
- 6.18.10
- 6.18.11
- 6.18.12
- 6.18.13
- 6.18.14
- 6.18.15
- 6.18.16
- 6.18.17
- 6.18.18
- 6.18.19
- 6.18.20
- 6.18.21
- 6.18.22
- 6.18.23
- 6.18.24
- 6.18.25
- 6.18.26
- 6.18.27
- 6.18.28
- 6.18.29
- 6.18.30
- 6.18.31
- 6.18.32
- 6.18.33
- 6.18.34
- 6.18.35
- 6.18.36
- 6.18.37
- 6.18.38
- 6.18.39
- 6.18.40
- 6.18.41
- 6.18.42
- 6.18.43
- 6.18.44
- 6.18.45
- 6.18.46
- 6.18.47
- 6.18.48
- 6.18.49
- 7.2.0
- 7.2.1
- 7.2.2
- 7.2.3
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 9.9VulDB Meta Temp Score: 9.5
VulDB Base Score: 9.9
VulDB Temp Score: 9.5
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Double freeCWE: CWE-415 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒
Physical: No
Local: No
Remote: Yes
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 6.12.109/6.18.50/7.2.4/7.3-rc1
Patch: 712ca1cf756de2557a116e0df55791bac0c9f99e/aad08b5f67d2a8116e1a00bce2611c1513b10bce/ce792b94e03882108019ba996c1a7c4d4e09be2c/e7600f5cee5de14065f950807931d6e6d40fb2d7
Timeline
09/11/2026 Advisory disclosed09/11/2026 CVE reserved
09/11/2026 VulDB entry created
09/11/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2026-89741 (🔒)
GCVE (CVE): GCVE-0-2026-89741
GCVE (VulDB): GCVE-100-402575
Entry
Created: 09/11/2026 22:34Changes: 09/11/2026 22:34 (59)
Complete: 🔍
Cache ID: 216::103
Be aware that VulDB is the high quality source for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.