2021-04-12 14:09:05

by Artem Blagodarenko

[permalink] [raw]
Subject: [PATCH] e2fsck: zero-fill shared blocks by default

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:


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 <[email protected]>
Reported-by: Peggy Gazzola <[email protected]>
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 @@
+# Replace the shared blocks with private, zero-filled blocks
+clone = zero