public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Joe Korty <joe.korty@ccur.com>
Cc: akpm@osdl.org, reinette.chatre@linux.intel.com,
	linux-kernel@vger.kernel.org, inaky@linux.intel.com
Subject: Re: [PATCH] bitmap: bitmap_parse takes a kernel buffer instead of a user buffer
Date: Wed, 4 Oct 2006 07:27:46 -0700	[thread overview]
Message-ID: <20061004072746.8e4b97a0.pj@sgi.com> (raw)
In-Reply-To: <20061004141405.GA22833@tsunami.ccur.com>

> I am slightly concerned about using a kmalloc where 'count' is specified
> by userspace.  There might be a DoS attack in here somewhere.....

Good point.  One should usually guard such a kmalloc, by checking the
count from user space against some crude upper limit, that is big
enough for any legitimate purposes, but avoids trying to allocate some
humongous amount.  For example, see kernel/cpuset.c:

        /* Crude upper limit on largest legitimate cpulist user might write. */
        if (nbytes > 100 + 6 * NR_CPUS)
                return -E2BIG;

> Perhaps we can reverse Andrew's idea: rename the existing bitmap_parse
> to bitmap_parse_user, then make the kernel-buffer version, bitmap_parse,
> be a wrapper around that.

Perhaps I should have my coffee first, but I don't see where the
order in which we wrap these affects the need to impose a crude
upper limit on what the user can ask for.

Off hand, I'd expect the kernel version to be the actual implementing
code, and the user version to be the wrapper and also to impose the
crude upper limit.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

  reply	other threads:[~2006-10-04 14:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-03 15:16 [PATCH] bitmap: bitmap_parse takes a kernel buffer instead of a user buffer Reinette Chatre
2006-10-03 15:20 ` inaky
2006-10-03 23:39 ` Andrew Morton
2006-10-04  2:03   ` Paul Jackson
2006-10-04 14:14   ` Joe Korty
2006-10-04 14:27     ` Paul Jackson [this message]
2006-10-04 14:55       ` Joe Korty
2006-10-04 15:06         ` Paul Jackson
2006-10-04 15:52           ` inaky
2006-10-04 16:40     ` Andrew Morton
2006-10-04 17:14       ` Joe Korty
2006-10-04 17:57         ` Inaky Perez-Gonzalez

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=20061004072746.8e4b97a0.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=akpm@osdl.org \
    --cc=inaky@linux.intel.com \
    --cc=joe.korty@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reinette.chatre@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox