All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Xiaotian Feng <dfeng@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, nhorman@tuxdriver.com,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Oleg Nesterov <oleg@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH v4] core_pattern: fix long parameters was truncated by core_pattern handler
Date: Tue, 24 Aug 2010 15:47:45 -0700	[thread overview]
Message-ID: <20100824154745.779ed12b.akpm@linux-foundation.org> (raw)
In-Reply-To: <1282642966-2296-1-git-send-email-dfeng@redhat.com>

On Tue, 24 Aug 2010 17:42:46 +0800
Xiaotian Feng <dfeng@redhat.com> wrote:

> We met a parameter truncated issue, consider following:
> > > echo "|/root/core_pattern_pipe_test %p /usr/libexec/blah-blah-blah \
> %s %c %p %u %g 11 12345678901234567890123456789012345678 %t" > \
> /proc/sys/kernel/core_pattern
> 
> This is okay because the strings is less than CORENAME_MAX_SIZE.
> "cat /proc/sys/kernel/core_pattern" shows the whole string. but
> after we run core_pattern_pipe_test in man page, we found last
> parameter was truncated like below:
>         argc[10]=<12807486>
> 
> The root cause is core_pattern allows % specifiers, which need to be
> replaced during parse time, but the replace may expand the strings
> to larger than CORENAME_MAX_SIZE. So if the last parameter is %
> specifiers, the replace code is using snprintf(out_ptr, out_end - out_ptr, ...),
> this will write out of corename array.
> 
> Changes since v3:
> make handling of single char also uses cn_printf, suggested by Andrew Morton.
> 
> Changes since v2:
> Introduced generic function cn_printf and make format_corename remember the time
> has been expanded, suggested by Olg Nesterov and Neil Horman.
> 
> Changes since v1:
> This patch allocates corename at runtime, if the replace doesn't have enough
> memory, expand the corename dynamically, suggested by Neil Horman.
> 
> I've tested with some core_pattern strings, it works fine now.

cool, thanks.

> 
> ...
>
> -static int format_corename(char *corename, long signr)
> +static int format_corename(struct core_name *cn, long signr)
>  {
>  	const struct cred *cred = current_cred();
>  	const char *pat_ptr = core_pattern;
>  	int ispipe = (*pat_ptr == '|');
> -	char *out_ptr = corename;
> -	char *const out_end = corename + CORENAME_MAX_SIZE;
> -	int rc;
>  	int pid_in_pattern = 0;
> +	int err = 0;
> +
> +	cn->size = CORENAME_MAX_SIZE * atomic_read(&call_count);
> +	cn->corename = kmalloc(cn->size, GFP_KERNEL);
> +	cn->used = 0;
> +
> +	if (!cn->corename)
> +		return -ENOMEM;
>  
>  	/* Repeat as long as we have more pattern to process and more output
>  	   space */
>  	while (*pat_ptr) {
>  		if (*pat_ptr != '%') {
> -			if (out_ptr == out_end)
> -				goto out;
> -			*out_ptr++ = *pat_ptr++;
> +			err = cn_printf(cn, "%c", *pat_ptr++);
>  		} else {
>  			switch (*++pat_ptr) {
> +			/* single % at the end, drop that */
>  			case 0:
> +				err = cn_printf(cn, "%c", '\0');

Confused.  Doesn't this bit just add another \0 to the end of an
already-null-terminated string?  And then make cn->used get out of sync
with strlen(cn->corename)?


  reply	other threads:[~2010-08-24 22:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-29 12:42 [RFC PATCH] core_pattern: fix long parameters was truncated by core_pattern handler Xiaotian Feng
2010-07-29 13:31 ` Neil Horman
2010-08-02 12:23   ` [RFC PATCH V2] " Xiaotian Feng
2010-08-02 13:50     ` Oleg Nesterov
2010-08-03 10:59       ` Neil Horman
2010-08-20  9:22         ` [RFC PATCH v3] " Xiaotian Feng
2010-08-20  9:35           ` Xiaotian Feng
2010-08-20  9:35         ` Xiaotian Feng
2010-08-23 11:07           ` Neil Horman
2010-08-23 23:02             ` KOSAKI Motohiro
2010-08-23 21:18           ` Andrew Morton
2010-08-24  6:18             ` Xiaotian Feng
2010-08-24  6:28               ` Andrew Morton
2010-08-24  9:42             ` [PATCH v4] " Xiaotian Feng
2010-08-24 22:47               ` Andrew Morton [this message]
2010-08-25  1:58                 ` Xiaotian Feng
2010-08-25  2:17                 ` [PATCH v5] " Xiaotian Feng
2010-08-02 14:30     ` [RFC PATCH V2] " Denys Vlasenko
2010-08-02 14:30       ` Denys Vlasenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100824154745.779ed12b.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dfeng@redhat.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.