full-disclosure - Re: Linux Kernel sctp_setsockopt() Integer Overflow

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]

From: mjt at tls.msk.ru (Michael Tokarev)
Subject: Re: Linux Kernel sctp_setsockopt() Integer Overflow

Shaun Colley wrote:
[]
> Below is the vulnerable call:
> 
> ---
> if (NULL == (tmp = kmalloc(optlen + 1, GFP_KERNEL))) {
>                         retval = -ENOMEM;
>                         goto out_unlock;
>                 }
> ---
> 
> Because kmalloc() takes the 'count' variable as an
> unsigned number, negative numbers are interpreted as
> large unsigned numbers.  However, if -1 is passed as
> 'optlen' (represented as 0xffffffff (hex) in unsigned
> variables, which is the largest value an unsigned
....
[]
> And thus, due to the integer overflow, 0 is passed to
> kmalloc(), causing too little memory to be allocated
> to hold 'optval'.

But kmalloc(0) will return NULL, and the whole setsockopt
will finish with errno set to ENOMEM.

 From 2.4 mm/slab.c:

void * kmalloc (size_t size, int flags)
{
         cache_sizes_t *csizep = cache_sizes;

         for (; csizep->cs_size; csizep++) {
                 if (size > csizep->cs_size)
                         continue;
                 return __kmem_cache_alloc(flags & GFP_DMA ?
                          csizep->cs_dmacachep : csizep->cs_cachep, flags);
         }
         return NULL;
}

So, where's the bug?

/mjt