lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ADC7AF5.2020707@agilent.com>
Date:	Mon, 19 Oct 2009 07:43:01 -0700
From:	Earl Chew <earl_chew@...lent.com>
To:	Johannes Weiner <hannes@...xchg.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Arithmetic overflow in may_expand_vm()

Johannes Weiner wrote:
>> If npages is stupendously large, the failure predicate may
>> return a false negative due to (cur + npages) overflowing and
>> wrapping.
> 
> Can this really happen?
> 
> npages always originates in a value of byte granularity, giving a
> theoretical maximum of ~0UL >> PAGE_SHIFT (checking for more than the
> number of addressable bytes just makes no sense).

I think you're saying that there are no (external facing)
interfaces that ask for pages -- they always ask for octets.

You may well be right. I don't know the kernel code base well
enough to say for sure one way or another.

> And mm->total_vm is always PAGE_SIZE times smaller than total user
> address space (which in turn is always less than ~0UL).
> 
> So I can not see this overflow being possible with PAGE_SHIFT > 0.

A very reasonable argument to be sure.

I can think of two counter-arguments:

a. The fewer assumptions made by may_expand_vm() (or any other
    function for that matter) about its callers, the more robust
    the function, and the more resilient the system.

    I think it would be good practice for may_expand_vm() to
    do the right thing for all possible input values. Especially
    in this case where the cost of doing the right thing is either
    very small or zero.

b. There are other examples in the code base that use the more
    robust approach. For instance see kernel/filemap.c:

         unsigned long limit =
            current->signal->rlim[RLIMIT_FSIZE].rlim_cur;

            ... snip ...

                 if (limit != RLIM_INFINITY) {
                         if (*pos >= limit) {
                                 send_sig(SIGXFSZ, current, 0);
                                 return -EFBIG;
                         }
                         if (*count > limit - (typeof(limit))*pos) {
                                 *count = limit - (typeof(limit))*pos;
                         }
                 }


Earl



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ