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
Powered by blists - more mailing lists
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.