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:0.021 / U:2.692 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site