When e2fsck detects multiply-claimed blocks, the default repair behavior is to clone the duplicate blocks. This is guaranteed to result in data corruption, and is also a security hole. Typically, one of the inodes with multiply-claimed blocks is valid, the others have corrupt extent data referencing some of the same disk blocks as the valid inode. e2fsck has no way to determine which inode is the rightful owner of the blocks. When e2fsck is run with the -y option and duplicate blocks are cloned, those duplicate data blocks from the valid inode or object are replicated to other objects. e2fsck has some extended options that provide different ways of handling duplicate blocks: clone=dup|zero shared=preserve|lost+found|delete The default behavior can be changed with modifications to the e2fsck.conf file. Let's set clone=zero and replace the shared blocks with private, zero-filled blocks. Leave shared=preserve because there are no reasons to move zeroed blocks somethere. This change doesn't touch e2fsprogs tests because they use their own enviroment and build their own e2fsck.conf Signed-off-by: Artem Blagodarenko <artem.blagodarenko@xxxxxxxxx> Reported-by: Peggy Gazzola <peggy.gazzola@xxxxxxx> HPE-bug-id: LUS-8408 --- e2fsck.conf | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 e2fsck.conf diff --git a/e2fsck.conf b/e2fsck.conf new file mode 100644 index 00000000..751b34cc --- /dev/null +++ b/e2fsck.conf @@ -0,0 +1,3 @@ +[options] +# Replace the shared blocks with private, zero-filled blocks +clone = zero -- 2.18.4
