Today I learned that there had been a faulty Debian kernel version which caused ext4 data corruption (bug 1057843) in December 2023.

Searching through the /var/log/aptitude and /var/log/apt logs, I noticed that the faulty kernel version was installed for one full day by /usr/bin/unattended-upgrade .

The chronology:

  • 09 Sep 2023 17:53 Rebooted system by hand
  • 07 Oct 2023 20:02 Upgrade via "aptitude" by hand: linux-image-amd64:amd64 6.1.52-1 -> 6.1.55-1
  • 10 Dec 2023 06:41 Unattended "apt" upgrade: linux-image-amd64:amd64 6.1.55-1 => 6.1.64-1 (installed faulty version)
  • 11 Dec 2023 07:00 Unattended "apt" upgrade: linux-image-amd64:amd64 6.1.64-1 => 6.1.66-1 (installed fixed version)
  • 16 Dec 2023 12:23 Upgrade via "aptitude" by hand: linux-image-amd64:amd64 6.1.66-1 -> 6.1.67-1
  • 18 Dec 2023 18:39 Rebooted system by hand

Although the faulty kernel version was installed at December, 10th, the system was not rebooted. Can I assume that I am not affected by the data correuption bug, since the faulty kernel did not boot? I am not 100% sure if the ext4 filesystem code is fully embedded in the kernel, or if changes to the ext4 module can apply on a running system.

1 Answer 1


As far as I understand, you are safe from this bug.

The only way to have the ext4 module changes to apply to the currently running non-buggy kernel would have been to first unmount all ext4 filesystems, then unload the old ext4 module and force-load the module from the buggy kernel version (overriding the kernel's preference to load the older version of the module intended for that particular kernel version), then remount all filesystems. If your root filesystem is ext4, it would be even more complicated.

No distribution I know has ever done anything like this, as it would cause a similar interruption to applications as a reboot would, so there would be no benefit.

While any ext4 filesystems are mounted, the current version of the ext4.ko kernel module is in use and cannot be unloaded.

The Debian 12 kernel seems to include the CONFIG_LIVEPATCH option, which would allow the patching of running kernel/module code, but it would require having specific livepatch modules provided for the specific kernel version that is going to be patched. As far as I know, Debian has not actually used this feature.

Anyway, if you have any livepatches applied, you should see them listed as extra kernel modules (presumably named like livepatch-<something>.ko), and also in /sys/kernel/livepatch/.

  • Thank you so much for your detailled and helpful answer! Feb 18 at 19:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .