2013-07-20 15:07:22

by Toralf Förster

[permalink] [raw]
Subject: fuzzying a user mode linux image often core dumps with

I do run the fuzzer trinity within a 32 bit user mode linux.
With latest git tree I do often get a core dump like the one attached.

Although it is the nature of trinity to corrupt the kernel /me wonders why it happens nearly alway
at the same place. That's why I decided to just report it here.


[New LWP 26743]
Core was generated by `/usr/local/bin/linux-v3.11-rc1-214-g6cc1862 earlyprintk ubda=/home/tfoerste/vir'.
Program terminated with signal 6, Aborted.
#0 0xb77b6424 in __kernel_vsyscall ()
#0 0xb77b6424 in __kernel_vsyscall ()
#1 0x083a3245 in kill ()
#2 0x0807163d in uml_abort () at arch/um/os-Linux/util.c:93
#3 0x08071925 in os_dump_core () at arch/um/os-Linux/util.c:138
#4 0x080613a7 in panic_exit (self=0x85a1518 <panic_exit_notifier>, unused1=0, unused2=0x85d6ce0 <buf.15904>) at arch/um/kernel/um_arch.c:240
#5 0x0809d588 in notifier_call_chain (nl=0x0, val=0, v=0x85d6ce0 <buf.15904>, nr_to_call=-2, nr_calls=0x0) at kernel/notifier.c:93
#6 0x0809d6d3 in __atomic_notifier_call_chain (nr_calls=<optimized out>, nr_to_call=<optimized out>, v=<optimized out>, val=<optimized out>, nh=<optimized out>) at kernel/notifier.c:182
#7 atomic_notifier_call_chain (nh=0x85d6cc4 <panic_notifier_list>, val=0, v=0x85d6ce0 <buf.15904>) at kernel/notifier.c:191
#8 0x08400a28 in panic (fmt=0x0) at kernel/panic.c:128
#9 0x0818a4b5 in ext4_orphan_add (handle=0x47870000, inode=0x47a06c60) at fs/ext4/namei.c:2571
#10 0x0818a6e5 in ext4_tmpfile (dir=0x479f5380, dentry=0x47a4b4d0, mode=0) at fs/ext4/namei.c:2319
#11 0x0810b7af in do_tmpfile (opened=<optimized out>, file=<optimized out>, op=<optimized out>, flags=<optimized out>, nd=<optimized out>, pathname=<optimized out>, dfd=<optimized out>) at fs/namei.c:2938
#12 path_openat (dfd=1201623936, pathname=0x47ce9040, nd=0x46effde4, op=0x46effe70, flags=67) at fs/namei.c:2981
#13 0x0810bcb1 in do_filp_open (dfd=-100, pathname=0x47ce9040, op=0x46effe70) at fs/namei.c:3043
#14 0x080fe5f8 in do_sys_open (dfd=0, filename=0x0, flags=4841986, mode=0) at fs/open.c:954
#15 0x080fe6c8 in SYSC_open (mode=<optimized out>, flags=<optimized out>, filename=<optimized out>) at fs/open.c:972
#16 SyS_open (filename=135073872, flags=4841986, mode=3127) at fs/open.c:967
#17 0x080618e2 in handle_syscall (r=0x46e0c7d4) at arch/um/kernel/skas/syscall.c:35
#18 0x08073c0d in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>, pid=<optimized out>) at arch/um/os-Linux/skas/process.c:198
#19 userspace (regs=0x46e0c7d4) at arch/um/os-Linux/skas/process.c:431
#20 0x0805e65c in fork_handler () at arch/um/kernel/process.c:160
#21 0x00000000 in ?? ()


--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3


2013-07-21 01:03:58

by Theodore Ts'o

[permalink] [raw]
Subject: Re: fuzzying a user mode linux image often core dumps with

On Sat, Jul 20, 2013 at 05:07:19PM +0200, Toralf F?rster wrote:
> I do run the fuzzer trinity within a 32 bit user mode linux.
> With latest git tree I do often get a core dump like the one attached.
>
> Although it is the nature of trinity to corrupt the kernel /me wonders why it happens nearly alway
> at the same place. That's why I decided to just report it here.

Thanks, this is a known problem for which the fix is can be found here:

http://patchwork.ozlabs.org/patch/260250/

I hope to get this fixed before -rc2 is released; the only question at
the moment is whether the fix is going to go to Linus via the ext4
tree or the VFS tree....

- Ted

2013-07-21 11:14:15

by Toralf Förster

[permalink] [raw]
Subject: Re: fuzzying a user mode linux image often core dumps with

On 07/21/2013 03:03 AM, Theodore Ts'o wrote:
> On Sat, Jul 20, 2013 at 05:07:19PM +0200, Toralf Förster wrote:
>> I do run the fuzzer trinity within a 32 bit user mode linux.
>> With latest git tree I do often get a core dump like the one attached.
>>
>> Although it is the nature of trinity to corrupt the kernel /me wonders why it happens nearly alway
>> at the same place. That's why I decided to just report it here.
>
> Thanks, this is a known problem for which the fix is can be found here:
>
> http://patchwork.ozlabs.org/patch/260250/
>
Ah - so no bisecting necessary.

> I hope to get this fixed before -rc2 is released; the only question at
> the moment is whether the fix is going to go to Linus via the ext4
> tree or the VFS tree....

yep - Linus had it now in its tree-.

BTW that issue seems to be the reason for a lot of erratically crashes
of an UML while fuzzy tested.

--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3