oss-sec mailing list archives

Re: CVE requests for three Linux kernel issues


From: P J P <ppandit () redhat com>
Date: Wed, 20 Nov 2013 12:19:47 +0530 (IST)

  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


Current thread: