oss-security - Re: CVE requests for three Linux kernel issues

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.10.1311201219380.1884@wniryva.cad.erqung.pbz>
Date: Wed, 20 Nov 2013 12:19:47 +0530 (IST)
From: P J P <ppandit@...hat.com>
To: oss security list <oss-security@...ts.openwall.com>
cc: Moritz Muehlenhoff <jmm@...ian.org>
Subject: Re: CVE requests for three Linux kernel issues

  Hello Moritz,

+-- On Tue, 19 Nov 2013, Petr Matousek wrote --+
| non-issues. Prasad (CC'ed) can provide reasons why.
| > XADV-2013008 Linux Kernel 3.11.7 <= sk_attach_filter Kernel Heap Corruption
| >   http://seclists.org/fulldisclosure/2013/Nov/139

   Here, integer overflow does not occur because 'fprog->len' is of type 
'unsigned short' and sizeof(struct sock_filter) = 8 bytes.

   unsigned int fsize = sizeof(struct sock_filter) * fprog->len;
                      = 8 * 65535(0xffff)
                      = 524280 => 0x0007fff8

===
    // XXX Integer overflow (+ sizeof(*fp)) and causing a little allocation.
    fp = sock_kmalloc(sk, fsize+sizeof(*fp), GFP_KERNEL);
===

Adding few more bytes 'sizeof(*fp)' to 'fsize' above is unlikely to overflow 
an unsigned int.

| > XADV-2013007 Linux Kernel bt8xx Video Driver IOCTL Heap Overflow
| >   http://seclists.org/fulldisclosure/2013/Nov/126

  Here, 'win->clipcount' is of type 'unsigned int' OR '__u32', which is 
checked for > 2048 in verify_window(). It returns an error if it is greater 
than 2048. If we set win->clipcount to '-3', it'll be seen as '4294967293', 
which is way greater than 2048. Thus avoiding the said heap overflow.

->> XADV-2013003 Linux Kernel fbdev Driver arcfb_write() Overflow
| >   http://seclists.org/fulldisclosure/2013/Nov/75

  Here, the call - write(/dev/fb, buf, count=0xffffffff) - passes through 
various VFS routines before reaching arcfb_write(). Enroute to 'arcfb_write', 
the routine vfs_write()->rw_verify_area() limits the 'count' argument to 
MAX_RW_COUNT via:

  #define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK) /* 2147479552|0x7ffff000 */

  return count > MAX_RW_COUNT ? MAX_RW_COUNT : count;

If count=MAX_RW_COUNT, the position parameter 'p' in arcfb_write() would have 
to be at least >= 0x80001000(ie. 2147487744), for 'count + position' to 
overflow an unsigned int fbmemlength at:

  if ((count + p) > fbmemlength)

But, that large a position value would not fall through an earlier check at

  fbmemlength = (xres * info->var.yres) / 8;
  if (p > bmemlength)
     return -ENOSPC;

Hope this helps. Thank you.
--
Prasad J Pandit / Red Hat Security Response Team

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.