EXT4 Data Corruption Bug Hits Three Stable Kernels

A patch has been pushed in the next release for the 3.6.x kernel

  Linux kernel logo
An EXT4 Data Corruption Bug has made its way into several stable kernels and has caused some mild panic, until it got resolved.

An EXT4 Data Corruption Bug has made its way into several stable kernels and has caused some mild panic, until it got resolved.

The bug was first introduced into Linux kernel 3.6.3, and that it was backported into 3.4x and 3.5.x branches. Not to worry, a patch is already being pushed into the kernel tree for the next stable release, and the older stable kernels should get the patches, as a later date.

The problem was reported on the official kernel mailing list and solved by Theodore Ts'o, one of the maintainers of EXT4. He also admitted that he didn't see the problem when he reviewed the patch that introduced it.

“If the journal's starting block is zero, we fail to truncate the journal when we unmount the file system. This can happen if we mount and then unmount the file system fairly quickly, before the log has a chance to wrap,” explained Theodore Ts'o.

“After the first time this has happened, it's not a disaster, but if this happens twice, the oldest valid transaction will still not have gotten updated, and when we then try to do the extra transaction replays, the metadata blocks can end up getting very scrambled indeed,” said the maintainer.

If you have one of the affected kernels, you should know that it only affects people who restart the operating system in quick succession and it probably won't affect a full install of the OS.

“Well, the problem won't show up if the journal has wrapped. So it will only show up if the system has been rebooted twice in fairly quick succession,” continued Ted Ts'o.

Keep in mind that both the 3.4.x and 3.5.x kernels are approaching end of life fast, so there is a chance, albeit small, that the patch might not get implemented.

Comments