lkml.org 
[lkml]   [2012]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: integer overflows in kernel/relay.c
On 02/07/2012 03:11 PM, Dan Carpenter wrote:
> My static checker is warning about integer overflows in kernel/relay.c
>
> relay_create_buf()
> 170
> 171 buf->padding = kmalloc(chan->n_subbufs * sizeof(size_t *), GFP_KERNEL);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This can only overflow on 32bit systems.

Correct

> 172 if (!buf->padding)
> 173 goto free_buf;
> 174
>
> relay_open()
> 582 chan->version = RELAYFS_CHANNEL_VERSION;
> 583 chan->n_subbufs = n_subbufs;
> 584 chan->subbuf_size = subbuf_size;
> 585 chan->alloc_size = FIX_SIZE(subbuf_size * n_subbufs);
> ^^^^^^^^^^^^^^^^^^^^^^^
> 586 chan->parent = parent;
>
> These come from the user in blk_trace_setup() and they aren't capped.
> I'm not sure what the maximum size to use is.

They are both u32 types, so can overflow on 32-bit as well. By default,
blktrace is using 4 for n_subbufs and 512k for subbuf_size, but they are
configurable. As a fix, I would suggest just checking if the products
overflow, and if they do, return an error. That's better than imposing
some hard limits. In reality, only a malicious users would trigger
these.

--
Jens Axboe



\
 
 \ /
  Last update: 2012-02-08 09:37    [W:3.756 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site