[lkml]   [2001]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [CHECKER] copy_*_user length bugs?
    On Tue, Apr 17, 2001 at 09:39:15PM -0700, Dawson Engler wrote:
    > Hi All,
    > at the suggestion of Chris ( I wrote a simple
    > checker to warn when the length parameter to copy_*_user was (1) an
    > integer and (2) not checked < 0.
    > As an example, the ipv6 routine rawv6_geticmpfilter gets an integer 'len'
    > from user space, checks that it is smaller than a struct size and then
    > uses length as an argument to copy_to_user:
    > if (get_user(len, optlen))
    > return -EFAULT;
    > if (len > sizeof(struct icmp6_filter))
    > len = sizeof(struct icmp6_filter);
    > if (put_user(len, optlen))
    > return -EFAULT;
    > if (copy_to_user(optval, &sk->tp_pinfo.tp_raw.filter, len))
    > return -EFAULT;
    > Is this a real bug? Or is the checked rule only applicable to
    > __copy_*_user routines rather than copy_*_user routines? (If its a real
    > bug, theres about 8 others that we found).

    The len parameter is an unsigned value, so this code is ok as
    long as access_ok() correctly checks that the range to copy
    doesn't stray outside of the userspace range, including the
    possible wraparound for a very large len. access_ok() on i386
    checks for the wraparound. m68k doesn't use it. PowerPC
    is correct, but only because TASK_SIZE is 0x80000000. If it
    is ever changed, there could be a problem. I didn't check
    other architectures, because I don't understand the asm.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:26    [W:0.022 / U:12.632 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site