oss-security September 2010 archive
Main Archive Page > Month Archives  > oss-security archives
oss-security: Re: [oss-security] CVE request: multiple kernel st

Re: [oss-security] CVE request: multiple kernel stack memory disclosures

From: Josh Bressers <bressers_at_nospam>
Date: Mon Sep 27 2010 - 20:25:05 GMT
To: oss-security@lists.openwall.com

Steve,

Can MITRE tackle this one. I don't have enough IDs for them all, and I'm
not sure of past precedence for putting some of these together.

Thanks.

--     JB ----- "Dan Rosenberg" <dan.j.rosenberg@gmail.com> wrote: > I'd like to request CVEs for a large series of Linux kernel stack > memory disclosure vulnerabilities, almost all of which have been > fixed.  They are all examples of declaring various structs on the > stack and copying them back to the user without filling in all the > fields, leaking uninitialized stack memory.  Since there are a lot of > issues here, I trust your judgment in deciding if they should each > receive a unique ID or if they should be combined in some way.  I > tried to break them up logically to make it easier. > > --- > > The first batch of issues occurred in the TIOCGICOUNT device ioctls > of > several device drivers.  While several of the issues were fixed on an > individual basis, Alan Cox fixed it for good by creating a new > handler.  Since these issues are essentially identical and were fixed > all at once, I think it might make sense to have them under a single > CVE.  Note that the final listed item in drivers/net/usb/hso.c was > already assigned CVE-2010-3298. > > "The TIOCGICOUNT device ioctl in mos7720.c, mos7840.c, serial_core.c, > hso.c, amiserial.c, and nozomi.c allows unprivileged users to read > uninitialized stack memory, because the 'reserved' member of the > serial_icounter_struct struct declared on the stack is not altered or > zeroed before being copied back to the user." > > > Alan Cox's fix: > http://lkml.org/lkml/2010/9/16/294 > > drivers/usb/serial/mos* > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a0846f1868b11cd827bdfeaf4527d8b1b1c0b098 > > drivers/serial/serial_core.c > http://userweb.kernel.org/~akpm/mmotm/broken-out/drivers-serial-serial_corec-prevent-reading-uninitialized-stack-memory.patch > > drivers/char/amiserial.c > http://userweb.kernel.org/~akpm/mmotm/broken-out/drivers-char-amiserialc-prevent-reading-uninitialized-stack-memory.patch > > drivers/char/nozomi.c > http://userweb.kernel.org/~akpm/mmotm/broken-out/drivers-char-nozomic-prevent-reading-uninitialized-stack-memory.patch > > drivers/net/usb/hso.c (CVE-2010-3298) > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7011e660938fc44ed86319c18a5954e95a82ab3e > > --- > > The next two issues both occurred in the FBIOGET_VBLANK device ioctl: > > "The FBIOGET_VBLANK device ioctl in sis_main.c and ivtvfb.c allows > unprivileged users to read 16 bytes of uninitialized stack memory, > because the 'reserved' member of the fb_vblank struct declared on the > stack is not altered or zeroed before being copied back to the user." > > drivers/video/sis/sis_main.c > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fd02db9de73faebc51240619c7c7f99bee9f65c7 > > drivers/media/video/ivtv/ivtvfb.c > lkml.org/lkml/2010/9/15/393 > > --- > > The following issues occured in miscellaneous device ioctls in a > variety of drivers.  Note the final two items listed have already > been > assigned CVE-2010-3296 and CVE-2010-3297 - I include them only for > reference. > > > sound/pci/rme9652/hdsp*.c > http://marc.info/?l=linux-kernel&m=128542726922720&w=2 > > "The SNDRV_HDSP_IOCTL_GET_CONFIG_INFO and > SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctls in hdspm.c and hdsp.c allow > unprivileged users to read uninitialized kernel stack memory, because > several fields of the hdsp{m}_config_info structs declared on the > stack are not altered or zeroed before being copied back to the > user." > > > drivers/video/via/ioctl.c > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b4aaa78f4c2f9cde2f335b14f4ca30b01f9651ca > > "The VIAFB_GET_INFO device ioctl allows unprivileged users to read > 246 > bytes of uninitialized stack memory, because the 'reserved' member of > the viafb_ioctl_info struct declared on the stack is not altered or > zeroed before being copied back to the user." > > > drivers/net/cxgb3/cxgb3_main.c (CVE-2010-3296) > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=49c37c0334a9b85d30ab3d6b5d1acb05ef2ef6de > > "The CHELSIO_GET_QSET_NUM device ioctl allows unprivileged users to > read 4 bytes of uninitialized stack memory, because the 'addr' member > of the ch_reg struct declared on the stack in cxgb_extension_ioctl() > is not altered or zeroed before being copied back to the user."  This > issue was assigned CVE-2010-3296. > > > drivers/net/eql.c (CVE-2010-3297) > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=44467187dc22fdd33a1a06ea0ba86ce20be3fe3c > > "The EQL_GETMASTRCFG device ioctl allows unprivileged users to read > 16 > bytes of uninitialized stack memory, because the 'master_name' member > of the master_config_t struct declared on the stack in > eql_g_master_cfg() is not altered or zeroed before being copied back > to the user."  This issue was assigned CVE-2010-3297. > > --- > > The final identified leak is in the sys_semctl system call, which I > would say is more serious since it is not driver-specific: > > ipc/sem.c > http://www.spinics.net/lists/mm-commits/msg80234.html > > "The semctl syscall has several code paths that lead to the leakage > of > uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO, > IPC_STAT, and SEM_STAT commands) during the use of the older, > obsolete > version of the semid_ds struct.  The copy_semid_to_user() function > declares a semid_ds struct on the stack and copies it back to the > user > without initializing or zeroing the 'sem_base', 'sem_pending', > 'sem_pending_last', and 'undo' pointers, allowing the leakage of 16 > bytes of kernel stack memory.  The code is still reachable on 32-bit > systems - when calling semctl() newer glibc's automatically OR the > IPC > command with the IPC_64 flag, but invoking the syscall directly > allows > users to use the older versions of the struct." > > --- > > Let me know if you have any questions or need any clarification on > any > of these issues. > > Regards, > Dan