Linux: Ext4 data corruption in 6.1.64-1

Original Article ↗ Hacker News Discussion ↗

A serious bug in the Linux 6.1.64 ext4 filesystem causes silent data corruption when files are written with direct I/O, prompting Debian to delay its 12.3 release and block the affected kernel package. Commenters examine how a mis-synchronized pair of upstream patches slipped into long-term stable kernels, raising broader concerns about the Linux stable backport process, the limits of “stable” distributions, and how quickly such issues can be detected and mitigated through distro infrastructure and user practices.

Scope and Nature of the Bug

  • ext4 data corruption occurs on certain Linux 6.1 stable kernels when using direct I/O (O_DIRECT), due to a backported ext4 change that depended on another direct-IO change that was not backported.
  • If both commits are present (e.g., in newer kernels), behavior is correct; if only the ext4 commit is present (e.g., 6.1.64/65), writes can go to the wrong offset.
  • Corruption is described as “non-catastrophic”: filesystem metadata remains intact, but individual files’ contents can be silently corrupted, especially bad for VM images and databases using O_DIRECT.

Upstream vs Debian Responsibility

  • Multiple comments stress this is an upstream stable-kernel bug, not a Debian-only patching issue; Debian tracks kernel.org stable releases.
  • Some confusion arises in the thread; others clarify using kernel changelogs and mailing list links that upstream 6.1.64 is affected and 6.1.66 contains the fix.
  • Some Ubuntu kernels are said to be unaffected because they don’t ship 6.1 by default.

Critique of the Stable Kernel Process

  • Strong criticism of the heavy backporting model: thousands of commits pulled into older LTS branches, with non-trivial dependency risk.
  • Concern that “stable” kernels change too fast and are now less stable than the rest of Debian; some prefer running only the latest mainline kernel instead.
  • Related incident: another missing dependent patch in 6.1.66 that broke Wi‑Fi, later fixed in 6.1.67, reinforcing doubts about the process.

Debian Handling and Updates

  • Users complain that unattended-upgrades pulled in the bad kernel even after the grave bug was known.
  • Explanations given: Debian’s archive tooling isn’t designed for instant revocation; new kernels must be built for many architectures and then propagate across mirrors that sync only a few times per day.
  • Workarounds discussed: pinning 6.1.64-1 with an apt preferences file, booting an older kernel, and properly disabling unattended-upgrades by stopping/disabling the .timer unit or reconfiguring the package.

Filesystems and Recovery

  • Some see this as undercutting claims that ext4 is inherently safer than ZFS or btrfs; others emphasize that all filesystems have bugs.
  • ext4 is praised for its mature fsck and simple metadata layout, claimed to allow recovery from almost any damage; skeptics question how much real user data that actually saves.

Severity and “Non-Serious Data Loss”

  • Debate over Debian’s terms: “grave” vs “non-serious data loss,” and whether corruption that can be fixed by fsck (or backups) counts as “recoverable” in practice.
  • Emphasis that silent corruption is especially dangerous because backups may silently ingest bad data.