linux-ext4 - Re: [sparc64] sigbus in e2fsck

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]

Date:   Tue, 30 Aug 2016 10:58:10 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc:     Anatoly Pugachev <matorola@...il.com>, linux-ext4@...r.kernel.org,
        debian-sparc <debian-sparc@...ts.debian.org>
Subject: Re: [sparc64] sigbus in e2fsck

On Tue, Aug 30, 2016 at 02:56:45PM +0200, John Paul Adrian Glaubitz wrote:
> On 08/30/2016 02:42 PM, Anatoly Pugachev wrote:
> > ../../e2fsck/recovery.c:866
> > 866                             blocknr = ext2fs_be64_to_cpu(* ((__u64
> > *) (bh->b_data+offset)));
> 
> The reason is that this expression is casting "char * b_data" [1] into u64 [2]
> which provokes unaligned access. Since such expression are often inevitable,
> it's probably best to modify the conversion macros in bitops.h [3] to be
> safe against unaligned accesses.

I don't think that's it.  b_data is a 4k buffer should be 8 byte
aligned.  For a file system with 64-bit blocks (which you presumably
have since we're on the be64 path as shown in your debugger output)
the offset is initially set to 16, and is incremented in chunks of 8
bytes.  So there shouldn't be any unaligned access.

Since you are able to provke this in a debugger, can you have gdb
print out the value of bh->b_data and offset, so we can be sure what's
going on?

I do see a potential problem which is that we're defining
journal_revoke_header_t structure in a non-portable way:

typedef struct journal_header_s
{
	__u32		h_magic;
	__u32		h_blocktype;
	__u32		h_sequence;
} journal_header_t;

typedef struct journal_revoke_header_s
{
	journal_header_t r_header;
	int		 r_count;	/* Count of bytes used in the block */
} journal_revoke_header_t;

The "int" above should be a __u32.  What is the size of int on
sparc64?  Is it by any chance 8 bytes?  If that's the problem then I'm
kind of surprised we haven't run into massive problems earlier, as
this looks like a long standing bug.

							- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html