Am 09.02.2012 11:44, schrieb Dan Carpenter:
> "subbuf_size" and "n_subbufs" come from the user and they need to be
> capped to prevent an integer overflow.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
>
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 4335e1d..ab56a17 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -164,10 +164,14 @@ depopulate:
> */
> static struct rchan_buf *relay_create_buf(struct rchan *chan)
> {
> - struct rchan_buf *buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);
> - if (!buf)
> + struct rchan_buf *buf;
> +
> + if (chan->n_subbufs > UINT_MAX / sizeof(size_t *))
> return NULL;
>
> + buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);
> + if (!buf)
> + return NULL;
> buf->padding = kmalloc(chan->n_subbufs * sizeof(size_t *), GFP_KERNEL);
> if (!buf->padding)
> goto free_buf;
> @@ -574,6 +578,8 @@ struct rchan *relay_open(const char *base_filename,
>
> if (!(subbuf_size && n_subbufs))
> return NULL;
> + if (subbuf_size > UINT_MAX / n_subbufs)
> + return NULL;
>
> chan = kzalloc(sizeof(struct rchan), GFP_KERNEL);
> if (!chan)
> --
numerical this is ok, but ...
maybe it is better to cap the chan->n_subbufs at a useful number ?
The user can still allocate an insane number of bytes.
Restricting subbuf_size*n_subbufs seems more logical (otherwise is this a real problem ?)
re,
wh
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
