Description of problem: The SNDRVHDSPIOCTLGETCONFIGINFO ioctl in hdsp.c allows unprivileged users to read uninitialized kernel stack memory, because several fields of the hdspmconfiginfo structs declared on the stack are not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/06/6 http://lkml.org/lkml/2010/9/25/41

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The FBIOGETVBLANK device ioctl in sismain.c allows unprivileged users to read 16 bytes of uninitialized stack memory, because the 'reserved' member of the fbvblank struct declared on the stack is not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/06/6 http://lkml.indiana.edu/hypermail//linux/kernel/1009.1/03385.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The compat ipc functions allow unprivileged users to read uninitialized stack memory, because some of the structures used and declared on the stack are not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/07/1 http://lkml.org/lkml/2010/10/6/492

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The "mem" array used as scratch space for socket filters is not initialized, allowing unprivileged users to leak kernel stack bytes.

http://www.spinics.net/lists/netdev/msg146361.html http://lists.grok.org.uk/pipermail/full-disclosure/2010-November/077321.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The semctl syscall has several code paths that lead to the leakage of uninitialized kernel stack memory (namely the IPCINFO, SEMINFO, IPCSTAT, and SEMSTAT commands) during the use of the older, obsolete version of the semidds struct. The copysemidtouser() function declares a semidds struct on the stack and copies it back to the user without initializing or zeroing the 'sembase', 'sempending', 'sempendinglast', 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 IPC64 flag, but invoking the syscall directly allows users to use the older versions of the struct.

Reference: http://www.openwall.com/lists/oss-security/2010/10/06/6 http://www.spinics.net/lists/mm-commits/msg80234.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The old shm interface allows unprivileged users to read uninitialized stack memory, because shmidds structure declared on the stack is not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/07/1 http://lkml.org/lkml/2010/10/6/454

Acknowledgements:

Red Hat would like to thank Vasiliy Kulikov of Openwall and Kees Cook for reporting this issue.

Description of problem: The SNDRVHDSPIOCTLGETCONFIGINFO ioctl in hdspm.c allows unprivileged users to read uninitialized kernel stack memory, because several fields of the hdspmconfiginfo structs declared on the stack are not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/06/6 http://lkml.org/lkml/2010/9/25/41

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: The VIAFBGETINFO device ioctl allows unprivileged users to read 1968 bytes of uninitialized stack memory, because the "reserved" member of the viafbioctlinfo struct declared on the stack is not altered or zeroed before being copied back to the user.

Reference: http://www.openwall.com/lists/oss-security/2010/10/06/6 http://lkml.indiana.edu/hypermail//linux/kernel/1009.1/03392.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Description of problem: There is a problem with the ioctl subsystem for drm, though it is most explicitly exposed by the intel GEM driver. Under driver-defined ioctls, drm does not sanitize the ioctl command, allowing the caller to specify how much memory should be kmalloc'd and copied back to the caller, regardless of what the driver ioctl actually does (it doesn't even need to succeed).

drivers/gpu/drm/drmdrv.c

long drmioctl(struct file filp, unsigned int cmd, unsigned long arg) ... unsigned int nr = DRMIOCTLNR(cmd); ... if ((nr >= DRMCOMMANDBASE) && (nr < DRMCOMMANDEND) && (nr < DRMCOMMANDBASE + dev->driver->numioctls)) ioctl = &dev->driver->ioctls[nr - DRMCOMMANDBASE]; ... if (cmd & (IOCIN | IOCOUT)) { if (IOCSIZE(cmd) <= sizeof(stackkdata)) { kdata = stackkdata; } else { kdata = kmalloc(IOCSIZE(cmd), GFPKERNEL); ... } } ... retcode = func(dev, kdata, filepriv); ... if (cmd & IOCOUT) { if (copytouser((void user )arg, kdata, IOCSIZE(cmd)) != 0) retcode = -EFAULT; }

"cmd" is caller-controlled, and can do whatever it likes for IOCSIZE(cmd), IOCIN and IOCOUT, resulting in leakage of previously freed kernel heap memory contents up to 16K in size.