linux-kernel - Re: [PATCH]: allow individual core dump methods to be unlimited when sending to a pipe

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, 24 Jul 2007 06:38:48 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, wwoods@...hat.com
Subject: Re: [PATCH]: allow individual core dump methods to be unlimited when sending to a pipe

On Tue, Jul 24, 2007 at 02:09:39AM -0700, Andrew Morton wrote:
> On Sun, 22 Jul 2007 11:39:47 -0400 Neil Horman <nhorman@...driver.com> wrote:
> 
> > 	This is a follow on to the patch entitled:
> > update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch
> > It allows individual core dump methods to have the core dump size limit passed
> > into them.  Its more efficient than each method having to retrieve it on their
> > own, and it allows for do_coredump to specify a infinite limit in the event that
> > a pipe is configured in /proc/sys/kernel/core_pattern, in which case ulimit -c
> > should not apply.
> 
> Needed this warning fix:
> 
> fs/exec.c: In function 'do_coredump':
> fs/exec.c:1761: warning: large integer implicitly truncated to unsigned type
> 
> diff -puN fs/exec.c~allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix fs/exec.c
> --- a/fs/exec.c~allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe-fix
> +++ a/fs/exec.c
> @@ -1703,7 +1703,7 @@ int do_coredump(long signr, int exit_cod
>  	int fsuid = current->fsuid;
>  	int flag = 0;
>  	int ispipe = 0;
> -	u32 core_limit = current->signal->rlim[RLIMIT_CORE].rlim_cur;
> +	unsigned long core_limit = current->signal->rlim[RLIMIT_CORE].rlim_cur;
>  
>  	audit_core_dumps(signr);
>  
> _
> 
> which makes me worry about how much care was taken here on 32/64 issues,
> and crsos-arch issues (the underlying type for compat_ulong_t, for one).
> 
> Could you please go over it with a toothcomb, see if there are any other
> slipups there?
> 
Yes, I had noticed this yesterday aternoon as well, Andrew. Sorry about that.
Upon looking at it using unsigned long should be the superset of all the
definitions, so I'm working on a patch to align that, and am testing it on all
the arches I have available here (x86, x86_64, ia64, and perhaps ppc64 if I can
get hold of it).  I also have a few more bugs that need fixing in the
core_pattern/pipe code as well as one more feature enhancement (the ability to
pass an argv array).  I'll fix up the bugs first, and you can expect these
patches in the next day or two.

Thanks & Regards
Neil
> 
> Thanks.

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@...driver.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/
-
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/