linux-kernel - Re: [PATCH] bitmap: bitmap_parse takes a kernel buffer instead of a user buffer

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: <20061004072746.8e4b97a0.pj@sgi.com>
Date:	Wed, 4 Oct 2006 07:27:46 -0700
From:	Paul Jackson <pj@....com>
To:	Joe Korty <joe.korty@...r.com>
Cc:	akpm@...l.org, reinette.chatre@...ux.intel.com,
	linux-kernel@...r.kernel.org, inaky@...ux.intel.com
Subject: Re: [PATCH] bitmap: bitmap_parse takes a kernel buffer instead of a
 user buffer

> 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@....com> 1.925.600.0401
-
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/