Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Nov 2010 19:47:29 -0500
From: Dan Rosenberg <>
To:, Petr Matousek <>
Subject: Re: CVE request: kernel: gdth: integer overflow in ioc_general()

This is not actually a security issue.  See the code:

if (!(buf = gdth_ioctl_alloc(ha, gen.data_len + gen.sense_len,
                                     FALSE, &paddr)))
            return -EFAULT;
if (copy_from_user(buf, arg + sizeof(gdth_ioctl_general),
                           gen.data_len + gen.sense_len)) {

If gen.data_len + gen.sense_len > UINT_MAX, then a small buffer will
be allocated.  But then the copy_from_user() will always fault before
copying any data over because the access_ok() check will fail on sizes
> UINT_MAX.  It's definitely a bug, but not a vulnerability.

On Mon, Nov 8, 2010 at 5:02 PM, Petr Matousek <> wrote:
> "gdth_ioctl_alloc() takes the size variable as an int.
> copy_from_user() takes the size variable as an unsigned long.
> gen.data_len and gen.sense_len are unsigned longs.
> On x86_64 longs are 64 bit and ints are 32 bit.
> We could pass in a very large number and the allocation would truncate
> the size to 32 bits and allocate a small buffer.  Then when we do the
> copy_from_user(), it would result in a memory corruption."
> Upstream commit:
> Credit: James E.J. Bottomley
> Reference:
> Thanks,
> --
> Petr Matousek / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.