linux-kernel - Re: Kernel 3.1.0-rc4 oops when connecting iPod

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:	Sun, 4 Sep 2011 01:37:41 +0100 (BST)
From:	Hin-Tak Leung <hintak_leung@...oo.co.uk>
To:	Pavel Ivanov <paivanof@...il.com>
Cc:	linux-fsdevel@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Kernel 3.1.0-rc4 oops when connecting iPod

--- On Sun, 4/9/11, Pavel Ivanov <paivanof@...il.com> wrote:

> On Sat, Sep 3, 2011 at 7:35 PM,
> >> So these 2 pointers are exactly what causing the
> trouble.
> >
> > This is interesting... so it would appear that
> hfsplus_read_wrapper() isn't working correctly, but enough
> of correct information to pass checks. I just re-read your
> e-mail and your device has a logical block size of 4096
> bytes, whereas most of the hfsplus code uses a block size of
> 512... you will need to look into hfsplus_submit_bio(),
> which is in the same file wrapper.c.
> 
> I've looked into the code myself a little and here's what I
> see.
> hfsplus_read_wrapper() calls to hfsplus_submit_bio() twice
> to fill
> sbi->s_vhdr and sbi->s_backup_vhdr. And according to
> parameters they
> are filled with pointers into sbi->s_vhdr_buf and
> sbi->s_backup_vhdr_buf respectively. It's done with the
> following code
> at fs/hfsplus/wrapper.c:79:
> 
>     if (!(rw & WRITE) && data)
>         *data = (u8 *)buf +
> offset;
> 
> So s_vhdr and s_backup_vhdr shouldn't be freed, s_vhdr_buf
> and
> s_backup_vhdr_buf should be freed instead. And indeed
> changing in
> hfsplus_fill_super()
> 
>     kfree(sbi->s_vhdr);
>     kfree(sbi->s_backup_vhdr);
> 
> to
> 
>     kfree(sbi->s_vhdr_buf);
>     kfree(sbi->s_backup_vhdr_buf);
> 
> fixes BUG reports from SLUB.

The code around there is a bit too dense, and both of the *_buf are recent introductions (and temp values, I think) as is hfsplus_submit_bio() itself, around the 2.6.39/3.0 time frame. I think the intention is to fill s_vhdr/s_backup_vhdr via mulitple fetches using *_buf as temp buffer.

> Now, the problem with "too large" error is trickier.
> According to this message
> 
> >> [   92.549197] hfs: filesystem size too large
> blksz_shift=14, total_blocks=486494
> 
> HFS thinks that my iPod has block size of 16 KiB. But
> generic_check_addressable() decides that everything with
> blocks larger
> than PAGE_CACHE_SHIFT (i.e. 4 KiB on my system) cannot be
> addressable
> and thus filesystem cannot be mounted. I guess it wasn't
> supposed to
> be that way. Is hfsplus_read_wrapper() wrong in determining
> block size
> or all iPods where this was tested actually had block size
> 4 KiB or
> less?

Your logical sector size is 4k according to dmesg and hfs block size is 512 so that 16KiB is a bit dodgy.

> > It is going to be difficult to do anything without the
> actual device and 8GB is too large to be send around.
> Assuming it is mostly music/media and there isn't too much
> stuff which is too confident/private, can I ask you to send
> me say, the first few MB of the disk?
> 
> I'll send it in a separate email bypassing lists.

Thanks - I got them now. It will take a while to find my way around though...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/