The Recent ext4 Data Corruption Bug

A few days ago an ext4 filesystem bug in stable kernels was found in stable kernels that can corrupt data. Such a bug in a filesystem is one of the worst one can imagine. Nobody likes losing data. Ext4 is also very widely used; it’s the default for Debian systems.

What Happened?

All of new kernel development ends up in Linus’ tree first. The v6.5 kernel development cycle included some ext4 bugfixes. Bugfixes, if self-contained and short enough, then get backported to stable kernels – older kernels that get community support after being released by Linus Torvalds.

In this case, the mistake was that one of said ext4 bugfix commits got backported into stable kernels, without investigating which other changes this bugfix might depend on. Here, some of the maintained stable kernels did *not* have a commit that it depends on, which led to the problem that affects only (older) stable kernels. These are the kernels that are supposed to be stable though, and distributions usually use them.

What makes this bug so unique? If you’ve *ever* installed a kernel that includes the bug, you have to expect your filesystem to be corrupted. That means at least it’d be wise to run fsck on it and so on. On critical systems, this is not trivial to deal with. Such bugs in Linux are very rare though. During the last 10 years no similar problem comes to mind.

Librem 5 Kernel Update Process

When looking at kernel.org, you see all kernels currently being maintained and supported. Some are marked “longterm”, some are “stable”.

For the Librem 5, we don’t use Debian’s kernel (based on the v6.1 longterm kernel) but create our own that is always based on “stable” kernels – currently v6.6. We simply don’t use very old kernels “far away” from Linus’ version. This saved us from being affected by this particular bug. No past Librem 5 kernel has been affected. Life goes on.

Recent Posts

Related Content

Tags