[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c0f216d1-edc1-68e6-7f3e-c00e33452707@oracle.com>
Date: Mon, 8 Jun 2020 09:45:49 +0200
From: Vegard Nossum <vegard.nossum@...cle.com>
To: Christoph Hellwig <hch@....de>
Cc: Kees Cook <keescook@...omium.org>,
Iurii Zaikin <yzaikin@...gle.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
bpf@...r.kernel.org, Andrey Ignatov <rdna@...com>
Subject: Re: WARNING: CPU: 1 PID: 52 at mm/page_alloc.c:4826
__alloc_pages_nodemask (Re: [PATCH 5/5] sysctl: pass kernel pointers to
->proc_handler)
On 2020-06-08 08:51, Christoph Hellwig wrote:
> On Thu, Jun 04, 2020 at 10:22:21PM +0200, Vegard Nossum wrote:
>> It's easy to reproduce by just doing
>>
>> read(open("/proc/sys/vm/swappiness", O_RDONLY), 0, 512UL * 1024 * 1024
>> * 1024);
>>
>> or so. Reverting the commit fixes the issue for me.
>
> Yes, doing giant allocations will fail and trace. We have to options
> here that both seems sensible:
>
> - trunate sysctrl calls to some sensible length
> - (optionally) use vmalloc
>
> Is this a real application or just a test case trying to do the
> stupidmost possible thing?
>
Just a test case.
Allowing the kernel to allocate an unbounded amount of memory on behalf
of userspace is an easy DOS.
All the length checks were already in there, e.g.
static int cmm_timeout_handler(struct ctl_table *ctl, int write,
void __user *buffer, size_t *lenp, loff_t
*ppos)
{
char buf[64], *p;
[...]
len = min(*lenp, sizeof(buf));
if (copy_from_user(buf, buffer, len))
return -EFAULT;
Vegard
Powered by blists - more mailing lists