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 "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 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: packetgetnamespkt() doesn't initialize all members of sadata field of sockaddr struct if strlen(dev->name) < 13. This structure is then copied to userland. It leads to leaking of contents of kernel stack memory. We have to fully fill sadata with strncpy() instead of strlcpy().
The same with packetgetname(): it doesn't initialize sllpkttype field of sockaddrll. Set it to zero.
Reference: http://marc.info/?l=linux-netdev&m=128854507220908&w=2 http://seclists.org/oss-sec/2010/q4/94
Acknowledgements:
Red Hat would like to thank Vasiliy Kulikov of Openwall for reporting this issue.
Description of problem: http://lkml.org/lkml/2010/9/11/167
The TIOCGICOUNT device ioctl allows unprivileged users to read 9 bytes of uninitialized stack memory, because the "reserved" member of the serialicounterstruct struct declared on the stack in hsogetcount() is not altered or zeroed before being copied back to the user. This patch takes care of it.
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Description of problem: Calling ETHTOOLGRXCLSRLALL with a large rulecnt will allocate kernel heap without clearing it. For the one driver (niu) that implements it, it will leave the unused portion of heap unchanged and copy the full contents back to userspace.
This is different from CVE-2010-2478, but was introduced at the same time (0853ad66, 2.6.27-rc1).
Upstream commit: http://git.kernel.org/linus/ae6df5f96a51818d6376da5307d773baeece4014
Acknowledgements:
Red Hat would like to thank Kees Cook for reporting this issue.