Vulnerability in linux (CVE-2026-43067, CVSS 9.8)

Summary

vulnerability in linux (CVE-2026-43067). Successful exploitation can lead to full system takeover.

Original description

The description as published by the source.

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: NIST National Vulnerability Database NVD GitHub Advisory

AI summary

Written by an external AI model and may contain mistakes. Check the original description and references below before acting on it.

This issue in the Linux kernel can lead to improper block allocation in the ext4 filesystem, posing a risk to system-wide data integrity. Similar issues have been seen in other filesystems before, requiring immediate attention. Your company should promptly update systems to the latest version.

This vulnerability in Linux kernel's ext4 allows blocks to be potentially allocated beyond group limits. Although the specific affected versions are not outlined, the fix involves adding a safety clamp in the ext4_mb_scan_groups() function. Attackers can exploit this flaw without authentication to manipulate system data. It is recommended to apply the related kernel patches to mitigate this issue.

❓ What is the problem

This vulnerability allows improper block allocation beyond specified group limits in the Linux kernel's ext4 filesystem.

📍 Affected scope

In the function ext4_mb_scan_groups() within the Linux kernel.

🔥 Severity

Critical, as per CVSS score of 9.8, allowing remote attacks without need for authentication.

🔧 How to fix

Apply the kernel patch that adds a safety clamp in ext4_mb_scan_groups().

🛡️ Workaround

No specific workaround provided.

🔍 Detection

Detect if ext4_mb_scan_groups() function is handling unexpected group limits in ext4 files.

Related past incidents Similar incidents extracted from past CVEs

CVE-2018-11401

An issue in the ext4 file system that allowed reading beyond a buffer boundary.

CVE-2019-11833

An ext4-related security vulnerability that allowed local users to corrupt file system.

CVE-2020-14314

An ext4 file system vulnerability related to improper block allocation.

If this happens at your company Expected impact per business scenario

📌 For cloud providers using OpenStack with ext4 file systems.

Tenants might experience data corruption or loss, affecting service availability.

📌 On enterprise servers using ext4 on Linux.

Could result in unauthorized block access, leading to potential data breaches.

📌 For companies running ext4 on critical systems.

Possible system-wide data corruption causing operational disruptions.

Recommended action

Apply updates to the Linux kernel to mitigate this risk as soon as a patch is available.

Response actions

Concrete steps and command examples for SOC/SRE teams to execute in order

1
Identify exposure identify
```
Audit SBOM/dependencies for affected components.
```
依存マニフェストで影響コンポーネントを特定する。
7
Post-deployment verification verify
```
Confirm patched version is live in production
```
パッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番では Step 3 と同じログクエリでアラート再発が無いか継続監視。

Affected packages

Linux Kernel

[{"type":"ECOSYSTEM","events":[{"introduced":"6.1.167"},{"fixed":"6.1.168"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.6.130"},{"fixed":"6.6.134"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.12.77"},{"fixed":"6.12.80"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.18.14"},{"fixed":"6.18.21"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.4"},{"fixed":"6.19.11"}]}]

Fix status by distribution

Fixed packages published by each distribution for this CVE

BellSoft Alpaquita BELL-CVE-2026-43067 linux-lts Fixed in: 6.1.168-r0
Debian DEBIAN-CVE-2026-43067 linux Fixed in: 6.19.11-1
Ubuntu UBUNTU-CVE-2026-43067 linux-hwe-edge

Vulnerability in linux (CVE-2026-43067)