A UNIX Symbolic Link (Symlink) Following vulnerability in chkstat of SUSE Linux Enterprise Server 12, SUSE Linux Enterprise Server 15, SUSE Linux Enterprise Server 11 set permissions intended for specific binaries on other binaries because it erroneously followed symlinks. The symlinks can't be controlled by attackers on default systems, so exploitation is difficult. This issue affects: SUSE Linux Enterprise Server 12 permissions versions prior to 2015.09.28.1626-17.27.1. SUSE Linux Enterprise Server 15 permissions versions prior to 20181116-9.23.1. SUSE Linux Enterprise Server 11 permissions versions prior to 2013.1.7-0.6.12.1.
The session-restore feature in Mozilla Firefox before 28.0 and SeaMonkey before 2.25 does not consider the Content Security Policy of a data: URL, which makes it easier for remote attackers to conduct cross-site scripting (XSS) attacks via a crafted document that is accessed after a browser restart.
Last updated 24 July 2024
An information leak flaw was found in the way way segmentation was performed on skbs originated from vhost-net when zerocopy feature was enabled. Once the source skb is consumed, ubuf destructor is called and potentially releases the corresponding userspace buffers, which can then for example be repurposed, while the destination skb could still be pointing to the them.
Acknowledgements:
This issue was discovered by Michael S. Tsirkin of Red Hat.
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
It was discovered that the Invariance Weakness of the RC4 stream cipher could be used to recover plaintext from a TLS connection, when RC4 encryption is used.
"The Invariance Weakness is an L-shape key pattern in RC4 keys, which once it exists in an RC4 key, preserves part of the state permutation intact throughout the initialization process. This intact part includes the least significant bits of the permutation, when processed by the PRGA algorithm, determines the least significant bits of the allegedly pseudo-random output stream along a long prefix of the stream."
This can lead to significant leakage of plaintext bytes from the ciphertext.
External Reference:
http://www.imperva.com/docs/HIIAttackingSSLwhenusingRC4.pdf
Last updated 24 July 2024
A flaw was found in the way the Linux kernel's floppy driver handled user space provided data in certain error code paths while processing FDRAWCMD IOCTL commands. A local user with write access to /dev/fdX could use this flaw to free (using the kfree() function) arbitrary kernel memory. (CVE-2014-1737, Important) It was found that the Linux kernel's floppy driver leaked internal kernel memory addresses to user space during the processing of the FDRAWCMD IOCTL command. A local user with write access to /dev/fdX could use this flaw to obtain information about the kernel heap arrangement. (CVE-2014-1738, Low) Note: A local user with write access to /dev/fdX could use these two flaws (CVE-2014-1737 in combination with CVE-2014-1738) to escalate their privileges on the system.
It was found that espfix funcionality (when returning to userspace with a 16 bit stack, the CPU will not restore the high word of esp for us on executing iret and thus potentially leaks kernel addresses; espfix fixes this) does not work for 32-bit KVM paravirt guests.
A local unprivileged user could potentially use this flaw to leak kernel stack addresses.
Proposed upstream patch: http://www.spinics.net/lists/kvm/msg111458.html
Acknowledgements:
Red Hat would like to thank Andy Lutomirski for reporting this issue.
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
Last updated 24 July 2024
An information leak vulnerability in rtnetlink subsystem in Linux kernel was found in "net/core/rtnetlink.c". The stack object "map" has a total size of 32 bytes. Its last 4 bytes are padding generated by compiler. These padding bytes are not initialized and sent out via nlaput().
Public via:
http://marc.info/?l=linux-kernel&m=146230821206492&w=2
http://marc.info/?l=linux-netdev&m=146230822606494&w=2
CVE-ID request and assignment:
http://seclists.org/oss-sec/2016/q2/234
http://seclists.org/oss-sec/2016/q2/237
Upstream patch:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=5f8e44741f9f216e33736ea4ec65ca9ac03036e6
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5f8e44741f9f216e33736ea4ec65ca9ac03036e6
Last updated 24 July 2024
Last updated 24 July 2024
Description of problem: This problem was originally tracked down by Brad Spengler.
When calling wireless ioctls, if a driver does not correctly validate/shrink iwp->length, the resulting copytouser can leak up to 64K of kernel heap contents.
It seems that this is triggerable[1] in 2.6.32 at least on ath5k, but I was not able to track down how. The twisty maze of ioctl handlers stumped me. :) Other drivers I checked did not appear to have any problems, but the potential remains. I'm not sure if this patch is the right approach; it was fixed differently[2] in grsecurity.
[1] http://forums.grsecurity.net/viewtopic.php?f=3&t=2290&start=0 [2] http://grsecurity.net/~spender/wireless-infoleak-fix2.patch
Discussion: http://lkml.org/lkml/2010/8/27/413
A flaw was found in the way Linux kernel's Journaling Block Device (JBD) handled invalid log first block value. An attacker able to mount malicious ext3 or ext4 image could use this flaw to crash the system.
Upstream commit: 8762202dd0d6e46854f786bdb6fb3780a1625efe
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: 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.
arch/x86/kvm/x86.c in the Linux kernel before 2.6.36.2 does not initialize certain structure members, which allows local users to obtain potentially sensitive information from kernel stack memory via read operations on the /dev/kvm device.
Last updated 24 July 2024
Description of problem: http://lkml.org/lkml/2010/9/11/168 The EQLGETMASTRCFG device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "mastername" member of the masterconfigt struct declared on the stack in eqlgmastercfg() is not altered or zeroed before being copied back to the user.
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.