Re: CVE request: kernel: gdth: integer overflow in ioc_general()

[Petr Matousek <pmatouse () redhat com>]

----- "Dan Rosenberg" <dan.j.rosenberg () gmail com> wrote:

> 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.

#define SIZE 0x10000029aUL

...
    volatile unsigned long t = SIZE;  // volatile so that it does not get optimised (error)

    printk("nada: %lx\n", current_thread_info()->addr_limit.seg);
    printk("nada2: %lx\n", access_ok(VERIFY_READ, 0, t));
    printk("nada3: %lx\n", t);
    printk("nada4: %lx\n", t > UINT_MAX);
...

nada: ffff810000000000
nada2: 1
nada3: 10000029a
nada4: 1

> On Mon, Nov 8, 2010 at 5:02 PM, Petr Matousek <pmatouse () redhat com>
> 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:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f63ae56e4e97fb12053590e41a4fa59e7daa74a4
> > Credit: James E.J. Bottomley
> >
> > Reference:
> > http://ns3.spinics.net/lists/linux-scsi/msg47361.html
> > https://bugzilla.redhat.com/show_bug.cgi?id=651147
> >
> > Thanks,
> > --
> > Petr Matousek / Red Hat Security Response Team