The extended attribute code now uses the crc32c checksum for hashing
purposes, so we should just always always initialize it. We also want
to prevent NULL pointer dereferences if one of the metadata checksum
features is enabled after the file sytsem is originally mounted.
https://bugzilla.kernel.org/show_bug.cgi?id=199183
Signed-off-by: Theodore Ts'o <[email protected]>
Cc: [email protected]
---
fs/ext4/super.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 9d1da40c1f62..7cd022c344d1 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3492,15 +3492,12 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
}
/* Load the checksum driver */
- if (ext4_has_feature_metadata_csum(sb) ||
- ext4_has_feature_ea_inode(sb)) {
- sbi->s_chksum_driver = crypto_alloc_shash("crc32c", 0, 0);
- if (IS_ERR(sbi->s_chksum_driver)) {
- ext4_msg(sb, KERN_ERR, "Cannot load crc32c driver.");
- ret = PTR_ERR(sbi->s_chksum_driver);
- sbi->s_chksum_driver = NULL;
- goto failed_mount;
- }
+ sbi->s_chksum_driver = crypto_alloc_shash("crc32c", 0, 0);
+ if (IS_ERR(sbi->s_chksum_driver)) {
+ ext4_msg(sb, KERN_ERR, "Cannot load crc32c driver.");
+ ret = PTR_ERR(sbi->s_chksum_driver);
+ sbi->s_chksum_driver = NULL;
+ goto failed_mount;
}
/* Check superblock checksum */
--
2.16.1.72.g5be1f00a9a
If some metadata block, such as an allocation bitmap, overlaps the
superblock, it's very likely that if the file system is mounted
read/write, the results will not be pretty. So disallow r/w mounts
for file systems corrupted in this particular way.
Signed-off-by: Theodore Ts'o <[email protected]>
Cc: [email protected]
---
fs/ext4/super.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 7cd022c344d1..edcfe6956eba 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2335,6 +2335,8 @@ static int ext4_check_descriptors(struct super_block *sb,
ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
"Block bitmap for group %u overlaps "
"superblock", i);
+ if (!sb_rdonly(sb))
+ return 0;
}
if (block_bitmap < first_block || block_bitmap > last_block) {
ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
@@ -2347,6 +2349,8 @@ static int ext4_check_descriptors(struct super_block *sb,
ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
"Inode bitmap for group %u overlaps "
"superblock", i);
+ if (!sb_rdonly(sb))
+ return 0;
}
if (inode_bitmap < first_block || inode_bitmap > last_block) {
ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
@@ -2359,6 +2363,8 @@ static int ext4_check_descriptors(struct super_block *sb,
ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "
"Inode table for group %u overlaps "
"superblock", i);
+ if (!sb_rdonly(sb))
+ return 0;
}
if (inode_table < first_block ||
inode_table + sbi->s_itb_per_group - 1 > last_block) {
--
2.16.1.72.g5be1f00a9a
Hi EXT4 ML!
I'm working on a project to perform automatic patch selection for
stable, and automate the testing being done for patches going in
various stable tree.
I got some input from the XFS folks so far, and wanted to get some
input from the EXT4 folks as well.
Below is a mail that would be sent as a response for ext4 patches
tagged for stable and sent to the mailing list. Since this one is
already tagged for stable, these results should be useful for people
to understand if the patch properly applies to various stable trees
and passes testing.
For EXT4, at this point testing is the xfstests tree at
https://github.com/tytso/xfstests , running with "./check -g auto".
Complete build and test logs are available in the links embedded in
the mail.
I'd be happy to get feedback for this. Thanks!
===
Hi Theodore Ts'o,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has also determined it's probably a bug fixing patch. (score: 90.6059)
The bot has tested the following trees: v4.15.12, v4.14.29, v4.9.89, v4.4.123, v4.1.50, v3.18.101.
v4.15.12: Build OK!
v4.14.29: Build OK!
v4.9.89: Build failed! Errors:
fs/ext4/super.c:2263:9: error: implicit declaration of function ‘sb_rdonly’ [-Werror=implicit-function-declaration]
v4.4.123: Build failed! Errors:
fs/ext4/super.c:2134:9: error: implicit declaration of function ‘sb_rdonly’ [-Werror=implicit-function-declaration]
v4.1.50: Build failed! Errors:
fs/ext4/super.c:2129:9: error: implicit declaration of function ‘sb_rdonly’ [-Werror=implicit-function-declaration]
v3.18.101: Build failed! Errors:
fs/ext4/super.c:2096:9: error: implicit declaration of function ‘sb_rdonly’ [-Werror=implicit-function-declaration]
EXT4 Specific tests:
v4.15.12 (http://stable-bot.westus2.cloudapp.azure.com/ext4-patch/v4.15.12/tests/):
Tests complete.
v4.14.29 (http://stable-bot.westus2.cloudapp.azure.com/ext4-patch/v4.14.29/tests/):
Tests complete.
v4.9.89 (http://stable-bot.westus2.cloudapp.azure.com/ext4-patch/v4.9.89/tests/):
No tests completed!
v4.4.123 (http://stable-bot.westus2.cloudapp.azure.com/ext4-patch/v4.4.123/tests/):
No tests completed!
v4.1.50 (http://stable-bot.westus2.cloudapp.azure.com/ext4-patch/v4.1.50/tests/):
No tests completed!
v3.18.101 (http://stable-bot.westus2.cloudapp.azure.com/ext4-patch/v3.18.101/tests/):
No tests completed!
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks,
Sasha
On 26.03.2018 07:49, Theodore Ts'o wrote:
> The extended attribute code now uses the crc32c checksum for hashing
> purposes, so we should just always always initialize it. We also want
> to prevent NULL pointer dereferences if one of the metadata checksum
> features is enabled after the file sytsem is originally mounted.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=199183
>
> Signed-off-by: Theodore Ts'o <[email protected]>
> Cc: [email protected]
> ---
> fs/ext4/super.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 9d1da40c1f62..7cd022c344d1 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3492,15 +3492,12 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
> }
>
> /* Load the checksum driver */
> - if (ext4_has_feature_metadata_csum(sb) ||
> - ext4_has_feature_ea_inode(sb)) {
> - sbi->s_chksum_driver = crypto_alloc_shash("crc32c", 0, 0);
> - if (IS_ERR(sbi->s_chksum_driver)) {
> - ext4_msg(sb, KERN_ERR, "Cannot load crc32c driver.");
> - ret = PTR_ERR(sbi->s_chksum_driver);
> - sbi->s_chksum_driver = NULL;
> - goto failed_mount;
> - }
> + sbi->s_chksum_driver = crypto_alloc_shash("crc32c", 0, 0);
> + if (IS_ERR(sbi->s_chksum_driver)) {
> + ext4_msg(sb, KERN_ERR, "Cannot load crc32c driver.");
> + ret = PTR_ERR(sbi->s_chksum_driver);
> + sbi->s_chksum_driver = NULL;
> + goto failed_mount;
> }
Why do you need to do all the manual initialization of the crc32c
lowlevel driver, when you can just make ext4 select LIBCRC32c and in the
code just use crc32c? Refer to include/linux/crc32c.h for the interface
and lib/libcrc32c.c for the low-level details.
>
> /* Check superblock checksum */
>