[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210408012323.110199-1-artem.blagodarenko@gmail.com>
Date: Wed, 7 Apr 2021 21:23:23 -0400
From: Artem Blagodarenko <artem.blagodarenko@...il.com>
To: linux-ext4@...r.kernel.org
Cc: adilger.kernel@...ger.ca,
Artem Blagodarenko <artem.blagodarenko@...il.com>
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:
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@...il.com>
Reported-by: Peggy Gazzola <peggy.gazzola@....com>
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
Powered by blists - more mailing lists