linux-kernel - Re: [REGRESSION] coredumps truncated after "new helper: dump

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: <8708646.IsEyNQP0iB@al>
Date:	Fri, 15 Nov 2013 22:34:43 +0100
From:	Peter Wu <lekensteyn@...il.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] coredumps truncated after "new helper: dump_align()"

On Friday 15 November 2013 20:38:38 Al Viro wrote:
> On Fri, Nov 15, 2013 at 03:26:10PM +0100, Peter Wu wrote:
> > Hi Al,
> > 
> > Somewhere in the merge window of 3.13, coredumps appear truncated.
> > Instead of 319488 bytes, I get 868 bytes (tested with x86_64 only).
> > 
> > The latest Linus' master (v3.12-9579-g049ffa8) is still affected.
> > Bisection leads to:
> > 
> > commit 22a8cb8248ba5d340307ba72432253b1dbdb5cf7
> > Author: Al Viro <viro@...iv.linux.org.uk>
> > Date:   Tue Oct 8 11:05:01 2013 -0400
> > 
> >     new helper: dump_align()
> >     
> >     dump_skip to given alignment...
> 
> Argh...  Really dumb braino when getting rid of long long division in
> dump_align().  Please, see if this gets rid of the entire problem on your
> setup - it definitely fixes a bug in there and it seems to restore the
> normal behaviour on the reproducer I've got here, but...
> 
> I'm going to send that to Linus, along with another coredump fix
> (dump_emit() ought to use __kernel_write() instead of vfs_write())
> shortly anyway, but if you spot anything still broken...
> 
> diff --git a/fs/coredump.c b/fs/coredump.c
> index 62406b6..a2856f7 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -733,7 +733,7 @@ int dump_align(struct coredump_params *cprm, int align)
>  {
>  	unsigned mod = cprm->written & (align - 1);
>  	if (align & (align - 1))
> -		return -EINVAL;
> -	return mod ? dump_skip(cprm, align - mod) : 0;
> +		return 0;
> +	return mod ? dump_skip(cprm, align - mod) : 1;
>  }
>  EXPORT_SYMBOL(dump_align);

Unfortunately, this patch still does not fix the issue. I rm'd the output 
directory just to be sure, but the bug is still there. What does this commit 
do anyway? The commit message is quite vague.

Please find the files to reproduce the bug in the tarball. Edit bisecter.sh to 
change the paths to the initrd, object output directory and serial output 
("dmesg") as needed.

The initrd should contain:
/init
/bin/busybox (statically linked)
/bin/segfault (also statically linked, source included)

initrd containing these three files can be generated with:
find | cpio --owner=root:root -H newc -o > initrd

The .config file (named qemucore.config) which I use for reproduction is also 
included. The resulting segfault program is 742752 bytes (stripped).
Download attachment "bisect-kernel.tar.gz" of type "application/x-compressed-tar" (8688 bytes)