linux-ext4 - Re: [PATCH] e2fsck: fix portability problems caused by unaligned accesses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <8E9C71E8-FE5F-4CB8-BA62-8D8895DCA92A@dilger.ca>
Date:   Tue, 4 May 2021 00:29:21 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>,
        harshads@...gle.com
Subject: Re: [PATCH] e2fsck: fix portability problems caused by unaligned
 accesses

On May 3, 2021, at 9:10 PM, Theodore Ts'o <tytso@....edu> wrote:
> 
> The on-disk format for the ext4 journal can have unaigned 32-bit
> integers.  This can happen when replaying a journal using a obsolete
> checksum format (which was never popularly used, since the v3 format
> replaced v2 while the metadata checksum feature was being stablized),
> and in the fast commit feature (which landed in the 5.10 kernel,
> although it is not enabled by default).
> 
> This commit fixes the following regression tests on some platforms
> (such as running 32-bit arm architectures on a 64-bit arm kernel):
> j_recover_csum2_32bit, j_recover_csum2_64bit, j_recover_fast_commit.
> 
> https://github.com/tytso/e2fsprogs/issues/65

Minor style comments inline.

> Addresses-Debian-Bug: #987641
> Signed-off-by: Theodore Ts'o <tytso@....edu>
> ---
> e2fsck/journal.c                   | 41 ++++++++++++++++++++---------
> e2fsck/recovery.c                  | 42 +++++++++++++++++++++++++-----
> tests/j_recover_fast_commit/script |  1 -
> 3 files changed, 65 insertions(+), 19 deletions(-)
> 
> diff --git a/e2fsck/journal.c b/e2fsck/journal.c
> index a425bbd1..2231b811 100644
> --- a/e2fsck/journal.c
> +++ b/e2fsck/journal.c
> @@ -344,10 +361,10 @@ static int ext4_fc_replay_scan(journal_t *j, struct buffer_head *bh,
> 						offsetof(struct ext4_fc_tail,
> 						fc_crc));
> 			jbd_debug(1, "tail tid %d, expected %d\n",
> -					le32_to_cpu(tail->fc_tid),
> +					get_le32(&tail->fc_tid),
> 					expected_tid);
> -			if (le32_to_cpu(tail->fc_tid) == expected_tid &&
> -				le32_to_cpu(tail->fc_crc) == state->fc_crc) {
> +			if (get_le32(&tail->fc_tid) == expected_tid &&
> +				get_le32(&tail->fc_crc) == state->fc_crc) {

(style) better to align continued line after '(' on previous line?  That way
it can be distinguished from the next (body) line more easily

> 				state->fc_replay_num_tags = state->fc_cur_tag;
> 			} else {
> 				ret = state->fc_replay_num_tags ?
> @@ -357,12 +374,12 @@ static int ext4_fc_replay_scan(journal_t *j, struct buffer_head *bh,
> 			break;
> 		case EXT4_FC_TAG_HEAD:
> 			head = (struct ext4_fc_head *)ext4_fc_tag_val(tl);
> -			if (le32_to_cpu(head->fc_features) &
> +			if (get_le32(&head->fc_features) &
> 				~EXT4_FC_SUPPORTED_FEATURES) {

(style) same

> 				ret = -EOPNOTSUPP;
> 				break;
> 			}
> -			if (le32_to_cpu(head->fc_tid) != expected_tid) {
> +			if (get_le32(&head->fc_tid) != expected_tid) {
> 				ret = -EINVAL;
> 				break;
> 			}


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)