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 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 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 ivtvfb.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.org/lkml/2010/9/15/393
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 TIOCGICOUNT device ioctl in both mos7720.c and mos7840.c allows unprivileged users to read uninitialized stack memory, because the "reserved" member of the serialicounterstruct 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.org/lkml/2010/9/15/392
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 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.
Last updated 24 July 2024
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.
The TSB I-TLB load implementation in arch/sparc/kernel/tsb.S in the Linux kernel before 2.6.33 on the SPARC platform does not properly obtain the value of a certain PAGEEXEC4U bit and consequently does not properly implement a non-executable stack, which makes it easier for context-dependent attackers to exploit stack-based buffer overflows via a crafted application.
Buffer overflow in the utilpathencode function in udev/lib/libudev-util.c in udev before 1.4.1 allows local users to cause a denial of service (service outage) via vectors that trigger a call with crafted arguments.
Description of problem: On x86-64, a 32-bit process (TIFIA32) can switch to 64-bit mode with ljmp, and then use the "syscall" instruction to make a 64-bit system call. A 64-bit process make a 32-bit system call with int $0x80.
In both these cases, auditsyscallentry() will use the wrong system call number table and the wrong system call argument registers. This could be used to circumvent a syscall audit configuration that filters based on the syscall numbers or argument details.
References: http://scary.beasts.org/security/CESA-2009-001.html http://scary.beasts.org/security/CESA-2009-004.html https://bugzilla.redhat.com/showbug.cgi?id=487255 http://lkml.org/lkml/2009/2/27/451 summary http://lkml.org/lkml/2009/2/27/452 syscall-audit