All of lore.kernel.org
 help / color / mirror / Atom feed
From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] Privilege dropping security module
Date: Fri, 25 Sep 2009 21:00:26 +0000 (UTC)	[thread overview]
Message-ID: <h9jb1a$url$2@taverner.cs.berkeley.edu> (raw)
In-Reply-To: 20090925100630.GD10098@c.hsd1.tn.comcast.net

Andy Spencer  wrote:
>static ssize_t dpriv_stage_write(struct file *filp, const char *ubuffer,
>		size_t length, loff_t *off)
>{
>	struct file *file;
>	int err, rval, perm;
>	char *kbuffer, *perm_str, *path_str;
>	int perm_start, perm_end, path_start;
>
>	if (!(kbuffer = kzalloc(length+1, GFP_KERNEL)))
>		return -ENOMEM;
>
>	if (copy_from_user(kbuffer, ubuffer, length))
>		goto fail_fault;

Can 'length+1' overflow?
(Can the caller arrange to pass MAX_SIZE_T as the length parameter?
If yes, that's a vulnerability.)
I haven't checked how dpriv_stage_write() is called, to see whether
this is possible.

>	/* Parse input */
>	path_start = -1;
>	sscanf(kbuffer, " %n%*s%n %n", &perm_start, &perm_end, &path_start);
>	if (path_start == -1)
>		goto fail_inval;
>	perm_str = kbuffer+perm_start;
>	kbuffer[perm_end] = '\0';
>	path_str = kbuffer+path_start;

What if kbuffer isn't '\0'-terminated?  Won't this read past the end
of kbuffer?

Are you certain that perm_end and path_start will be within bounds?
If the user supplies a sufficiently large string (more than MAX_INT
characters long), could perm_end or path_start be negative?

>	rval = length;

Converts size_t to ssize_t.

  parent reply	other threads:[~2009-09-25 21:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-23  0:56 [RFC] Privilege dropping security module Andy Spencer
2009-09-23 20:46 ` Casey Schaufler
2009-09-23 22:31   ` Andy Spencer
2009-09-23 23:03     ` Tetsuo Handa
2009-09-24 16:37     ` David Wagner
2009-09-25  7:22       ` Andy Spencer
2009-09-25 20:48         ` David Wagner
2009-09-26 21:09           ` Andy Spencer
2009-09-27  0:28             ` David Wagner
2009-10-01  7:38     ` Pavel Machek
2009-10-01  9:15       ` Andy Spencer
2009-10-01 10:42         ` Pavel Machek
2009-09-23 21:31 ` [RFC][PATCH] " Andy Spencer
2009-09-24 16:25   ` Casey Schaufler
2009-09-25 10:06     ` Andy Spencer
2009-09-25 16:23       ` Casey Schaufler
2009-09-26 21:35         ` Andy Spencer
2009-09-28  5:38           ` Rob Meijer
2009-09-25 21:00       ` David Wagner [this message]
2009-09-29  7:36         ` Andy Spencer
2009-09-29  7:10 ` [RFC][PATCH] Permission masking security module (was dpriv) Andy Spencer
2009-09-29 17:44   ` Greg KH
2009-09-30  0:18     ` Andy Spencer
2009-10-01  2:33   ` Casey Schaufler

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='h9jb1a$url$2@taverner.cs.berkeley.edu' \
    --to=daw@cs.berkeley.edu \
    --cc=daw-news@cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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.