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 tytso@mit.edu Cc: stable@vger.kernel.org --- 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 */
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 tytso@mit.edu Cc: stable@vger.kernel.org --- 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) {
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 tytso@mit.edu Cc: stable@vger.kernel.org
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 */
linux-stable-mirror@lists.linaro.org