CyberSecBulletin
CVE-2026-43067NVD status: Modified

Linux: Untrusted Pointer Dereference

Published Updated By the CyberSecBulletin desk

CVE-2026-43067 is a critical-severity untrusted pointer dereference vulnerability in Linux, with a CVSS 3.1 base score of 9.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions f89bba144938921a2249237ad04a0183ff3f8930, 83170a05908b6cf2fb3235d3065bf613ff866f3c, 4bec4a498ce86314d470ae6144120461f2138c29 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.5% chance of exploitation within 30 days, which is low compared with other CVEs.

Patch this week

Critical severity: a successful attack would have severe impact.

What to do

  1. Update Linux to f89bba144938921a2249237ad04a0183ff3f8930 or 83170a05908b6cf2fb3235d3065bf613ff866f3c or 4bec4a498ce86314d470ae6144120461f2138c29 or 12624c5b724a81e14e532972b40d863b0de3b7d1, whichever matches your release line, or a later version.
  2. Update Linux Kernel to 5.16 or 6.6.134 or 6.12.80 or 6.18.21, whichever matches your release line, or a later version.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux9d89b9d55e25cb340c5b4b769876edc551b7a9ff up to, but not including, f89bba144938921a2249237ad04a0183ff3f8930; 1b0edd6022a3f44ce87fea9959a9310f4628fbea up to, but not including, 83170a05908b6cf2fb3235d3065bf613ff866f3c; 9eea2f57d11b30049ff996ac3eff6e0dc8089e5f up to, but not including, 4bec4a498ce86314d470ae6144120461f2138c29; 34c803edc0b3365a42efcf9815acab63b4cf54e0 up to, but not including, 12624c5b724a81e14e532972b40d863b0de3b7d1; 321ed8d559c951e71ad2d2d69a4cf0445644e865 up to, but not including, 2a368ccddfc492a0aa951e2caef2985f20e96503; 4865c768b563deff1b6a6384e74a62f143427b42 up to, but not including, bb81702370fad22c06ca12b6e1648754dbc37e0f; 16fce6b6c0b247258c6c217fce5a48abf50f6964; 5.15.203 up to, but not including, 5.16; and 5 more rangesf89bba144938921a2249237ad04a0183ff3f8930, 83170a05908b6cf2fb3235d3065bf613ff866f3c, 4bec4a498ce86314d470ae6144120461f2138c29, 12624c5b724a81e14e532972b40d863b0de3b7d1, 2a368ccddfc492a0aa951e2caef2985f20e96503, bb81702370fad22c06ca12b6e1648754dbc37e0f
LinuxLinux Kernel5.15.203 up to, but not including, 5.16; 6.6.130 up to, but not including, 6.6.134; 6.12.77 up to, but not including, 6.12.80; 6.18.14 up to, but not including, 6.18.21; 6.19.4 up to, but not including, 6.19.11; 6.1.1675.16, 6.6.134, 6.12.80, 6.18.21, 6.19.11

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Official description

In the Linux kernel, the following vulnerability has been resolved: ext4: handle wraparound when searching for blocks for indirect mapped blocks Commit 4865c768b563 ("ext4: always allocate blocks only from groups inode can use") restricts what blocks will be allocated for indirect block based files to block numbers that fit within 32-bit block numbers. However, when using a review bot running on the latest Gemini LLM to check this commit when backporting into an LTS based kernel, it raised this concern: If ac->ac_g_ex.fe_group is >= ngroups (for instance, if the goal group was populated via stream allocation from s_mb_last_groups), then start will be >= ngroups. Does this allow allocating blocks beyond the 32-bit limit for indirect block mapped files? The commit message mentions that ext4_mb_scan_groups_linear() takes care to not select unsupported groups. However, its loop uses group = *start, and the very first iteration will call ext4_mb_scan_group() with this unsupported group because next_linear_group() is only called at the end of the iteration. After reviewing the code paths involved and considering the LLM review, I determined that this can happen when there is a file system where some files/directories are extent-mapped and others are indirect-block mapped. To address this, add a safety clamp in ext4_mb_scan_groups().

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Untrusted Pointer Dereference

The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.

More Untrusted Pointer Dereference vulnerabilities (CWE-822)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Untrusted Pointer Dereference vulnerabilities

Spotted an error? Tell us.