linux-kernel - Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

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, 19 Jun 2012 07:59:54 +0200
From:	Torsten Hilbrich <torsten.hilbrich@...unet.com>
To:	Jeff Moyer <jmoyer@...hat.com>
CC:	linux-ext4@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Kernel 3.3.8 breaks accidental ext3 mount of extended partition

Am 18.06.2012 21:03, schrieb Jeff Moyer:
> Torsten Hilbrich <torsten.hilbrich@...unet.com> writes:
> 
>> Hello,
>>
>> a software that tries to mount each existing partition as ext3 file
>> system started to fail when updating from v3.3.7 to v3.3.8.
>>
>> The applications then hangs-up in the mount syscall, here is a
>> snapshot of its stack at this moment:
>>
>> [<ffffffff81060c6a>] __cond_resched+0x2a/0x40
>> [<ffffffff81134b3f>] __getblk+0x1bf/0x270
>> [<ffffffff811362b3>] __bread+0x13/0xb0
>> [<ffffffff81182222>] ext3_fill_super+0x132/0x1b00
>> [<ffffffff8110891a>] mount_bdev+0x1aa/0x1f0
>> [<ffffffff8117ffc5>] ext3_mount+0x15/0x20
>> [<ffffffff81107fc3>] mount_fs+0x43/0x1a0
>> [<ffffffff81123102>] vfs_kern_mount+0x72/0x100
>> [<ffffffff81123882>] do_kern_mount+0x52/0x110
>> [<ffffffff8112519a>] do_mount+0x25a/0x7d0
>> [<ffffffff811257a8>] sys_mount+0x98/0xf0
>> [<ffffffff814f3e92>] system_call_fastpath+0x16/0x1b
>>
>> The expected behaviour (which was still there in v3.3.7) is that the
>> mount syscall fails because the partition contains no valid ext3 file
>> system.
>>
>> I have create more snapshot of the stack in the following pastebin:
>> http://pastebin.com/99x9EpnM
>>
>> Using bisecting I found the following commit to be the cause of the issue:
>>
>> commit 3735b0a1d73af536484ddefef4d8438dd468c4a6
>> Author: Jeff Moyer <jmoyer@...hat.com>
>> Date:   Fri May 11 16:34:10 2012 +0200
>>
>>     block: don't mark buffers beyond end of disk as mapped
>>     
>>     commit 080399aaaf3531f5b8761ec0ac30ff98891e8686 upstream.
>>     
>> Reverting this commit brought back the desired behaviour of the mount
>> syscall failing because of invalid superblock.
>>
>> It seems to be that ext3_fill_super is unable to read the super block
>> because there is no blocked for an extended partition.
>>
>> The same issue can be found in v3.4, where the upstream commit
>> (080399aa) was released.
> 
> I am unable to reproduce this behaviour.  Can you give more information
> about your storage configuration?  What is the partition layout, which
> partition are you trying to mount, and are you using the standard mount
> command to try to mount it?  Is there anything else you can provide that
> would help me reproduce the problem?

The system where I reproduced the problem upstream is an amd64 based
ubuntu 12.04 installation. I used both v3.3.8 and v3.4 for reproducing.

The partition layout is the following:

======================================================================

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x1669c708

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63    86285114    43142526   83  Linux
/dev/sda2       216797175   234436544     8819685   82  Linux swap / Solaris
/dev/sda3        86285115    87088364      401625   83  Linux
/dev/sda4        87088426   216797174    64854374+   5  Extended
/dev/sda5        87088428    91104614     2008093+  83  Linux
/dev/sda6        91104678   216797174    62846248+  8e  Linux LVM

Partition table entries are not in disk order

======================================================================

The extented partition is /dev/sda4 in this example. NOTE: The software
which triggered the problem is really dumb, it tries to mount each block
devices and assumes that any mount for a non-ext3 fs will simply fail.

I perform the following steps to trigger the problem:

- boot into the test kernel (with serial console and init=/bin/bash)

- mount -o ro -t ext3 /dev/sda4 /mnt

This mount call will hang up with stack traces shown above and in the
pastebin entry.

I will append the complete kernel configuration for the v3.4 build as
attachment to this mail (kernel.config).

I also attached the kernels log output (ext3-mount-bug.log). At the end
of the log you will find the outputs of SysRq
show-backtrace-all-active-cpus (line 665), show-blocked-tasks (line 744,
which is empty), and show-task-states (line 746). Starting at line 1362
is the output for the mount command a few seconds after starting the
command.

I hope, these information help in identifying the problem.

	Torsten


View attachment "kernel.config" of type "text/plain" (89323 bytes)

View attachment "ext3-mount-bug.log" of type "text/x-log" (72020 bytes)