A memory leak was found in the way libpng processed malformed Portable Network Graphics (PNG) images with Physical Scale (sCAL) extension. A remote attacker could create a specially-crafted PNG image and trick the local user into opening it in an application, using the libpng library, leading to denial of service (relevant libpng-based application crash).
References: [1] http://www.libpng.org/pub/png/libpng.html
CVE Request: [2] http://www.openwall.com/lists/oss-security/2010/06/28/2
Description of problem: Structure sockaddrtipc is copied to userland with padding bytes after "id" field in union field "name" unitialized. It leads to leaking of contents of kernel stack memory. We have to initialize them to zero.
Reference: http://marc.info/?l=linux-netdev&m=128854507420917&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: Due to bad parsing of malformed X.25 facilities, a remote attacker can cause a kernel panic due to heap corruption (assuming both parties are communicating using X.25).
Reference: http://www.spinics.net/lists/netdev/msg145786.html http://www.spinics.net/lists/netdev/msg145873.html
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Description of problem: Sometimes ax25getname() doesn't initialize all members of fsadigipeater field of fsa struct. This structure is then copied to userland. It leads to leaking of contents of kernel stack memory. We have to initialize them to zero.
Reference: http://marc.info/?l=linux-netdev&m=128854507120898&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: 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: In bcmconnect() (in net/can/bcm.c), there is the following code:
sprintf(bo->procname, "%p", sock);
"procname" is a 9-byte char array. On 64-bit platforms, up to 17 bytes may be copied into the buffer. Fortunately, structure padding will most likely prevent this from being a problem, except for the trailing NULL byte, which may overwrite the first byte of the next heap object.
Reference: http://www.spinics.net/lists/netdev/msg145791.html
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Last updated 24 July 2024
Last updated 24 July 2024
Description of problem: INET-DIAG is inconsistent about how it looks up the bytecode contained in a netlink message, making it possible for a user to cause the kernel to execute unaudited INET-DIAG bytecode. This can be abused to make the kernel enter an infinite loop, and possibly other consequences.
Reference: http://www.spinics.net/lists/netdev/msg145899.html
Acknowledgements:
Red Hat would like to thank Nelson Elhage for reporting this issue.
Description of problem: Reported by Nelson Elhage.
CVE-2010-3848 AFECONET kernel stack overflow CVE-2010-3849 AFECONET saddr->cookie NULL dereferences CVE-2010-3850 AFECONET SIOCSIFADDR ioctl does not check privileges
The two main vulnerabilities lie in the econetsendmsg() function. If CONFIGECONETAUNUDP, the function declares a variable-length array of iovec's on the stack:
static int econetsendmsg(struct kiocb iocb, struct socket sock, struct msghdr msg, sizet len) { ... #ifdef CONFIGECONETAUNUDP ... struct iovec iov[msg->msgiovlen+1]; ... #endif
"msg->msgiovlen" is a user-controlled value <= 1024; 1024 'struct iovec's is enough to overflow the kernel stack and clobber the 'threadinfo' struct on either 32- or 64-bit systems with or without CONFIG4KSTACKS.
The code populates 'iov' with user-controlled values, so this is almost certainly exploitable for privesc.
The second bug is conveniently labeled as such for anyone who cares to look:
/ BUG: saddr may be NULL / eb->cookie = saddr->cookie;
In fact, 'saddr' comes from userspace and may be NULL (if non-NULL, it will have been copied to kernelspace), leading to a NULL-pointer dereference. This saddr->cookie dereference appears twice, once in the "hardware" case and once in the "UDP emulation" case. This is easily exploitable for an oops, but probably not anything more.
The final issue is in the ecdevioctl function. The SIOCSIFADDR ioctl does not check privileges, allowing an unprivileged user to assign econet addresses to arbitrary interfaces. It is possible this is intentional, but AFAIK it would be unusual for SIOCSIFADDR to be unprivileged, so this may be an accident.
Note that it is necessary to use this property in order to make the first two bugs exploitable, since econetsendmsg will return almost immediately if no econet addresses are configured.
Reference: http://seclists.org/oss-sec/2010/q4/236
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.
Description of problem: http://lkml.org/lkml/2010/9/11/170 The CHELSIOGETQSETNUM device ioctl allows unprivileged users to read 4 bytes of uninitialized stack memory, because the "addr" member of the chreg struct declared on the stack in cxgbextensionioctl() 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.
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.
Last updated 24 July 2024
Description of problem: Changes to tty to use struct pid happened here: ab521dc0f8e117fd808d3e425216864d60390500
mrg-1/rhel-6 are missing: 1) redo locking of tty->pgrp 47f86834bbd4193139d61d659bebf9ab9d691e37 2) tty: fix race in ttyfasync 703625118069f9f8960d356676662d3db5a9d116 3) fnctl: fmodown should call writelockirqsave/restore b04da8bfdfbbd79544cab2fadfdc12e87eb01600
Buffer overflow in pngpread.c in libpng before 1.2.44 and 1.4.x before 1.4.3, as used in progressive applications, might allow remote attackers to execute arbitrary code via a PNG image that triggers an additional data row.
Description of problem: The CONFIGSTACKGROWSDOWN variant of setupargpages() does not check the size of the argument/environment area on the stack. When it is unworkably large, shiftargpages() hits its BUGON. This is exploitable with a very large RLIMITSTACK limit, to create a crash pretty easily. Check that the initial stack is not too large to make it possible to map in any executable. We're not checking that the actual executable (or intepreter, for binfmtelf) will fit. So those mappings might clobber part of the initial stack mapping. But that is just userland lossage that userland made happen, not a kernel problem.
Upstream commit: http://git.kernel.org/linus/1b528181b2ffa14721fb28ad1bd539fe1732c583
Reference: http://grsecurity.net/~spender/64bitdos.c
Acknowledgements:
Red Hat would like to thank Brad Spengler for reporting this issue.
Last updated 24 July 2024
Description of problem: User "foo" can use the SWAPEXT ioctl to swap a write-only file owned by user "bar" into a file owned by "foo" and subsequently reading it. It does so by checking that the file descriptors passed to the ioctl are also opened for reading.
References: http://archives.free.net.ph/message/20100616.130710.301704aa.en.html http://archives.free.net.ph/message/20100616.135735.40f53a32.en.html
Apache Portable Runtime (APR) is vulnerable to a denial of service, caused by an error in the aprfnmatch() function when processing specific patterns with the "" wildcard. A remote attacker could exploit this vulnerability to consume all available CPU and memory resources resulting in a denial of service.
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-7220 to the following vulnerability:
Unspecified vulnerability in Prototype JavaScript framework (prototypejs) before 1.6.0.2 allows attackers to make "cross-site ajax requests" via unknown vectors.
References: ------------ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7220 http://github.com/sstephenson/prototype/blob/master/CHANGELOG http://osvdb.org/46312
Upstream patch: --------------- git clone git://github.com/sstephenson/prototype.git git show 02cc9992e915c024650ddc77a91064f7a4252914
The relevant file in WordPress source rpm package (F10) is: ------------------------------------------------------------ BUILD/wordpress/wp-includes/js/prototype.js
cupsd in CUPS 1.3.9 and earlier allows local users, and possibly remote attackers, to cause a denial of service (daemon crash) by adding a large number of RSS Subscriptions, which triggers a NULL pointer dereference. NOTE: this issue can be triggered remotely by leveraging CVE-2008-5184.
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-4796 to the following vulnerability:
The httpsrequest function (Snoopy/Snoopy.class.php) in Snoopy 1.2.3 and earlier allows remote attackers to execute arbitrary commands via shell metacharacters in https URLs. NOTE: some of these details are obtained from third party information.
References: http://sourceforge.net/forum/forum.php?forumid=879959 http://jvn.jp/en/jp/JVN20502807/index.html http://jvndb.jvn.jp/ja/contents/2008/JVNDB-2008-000074.html http://www.frsirt.com/english/advisories/2008/2901 http://secunia.com/advisories/32361
Created attachment 320281 [details] Proposed actualized upstream qemu patch to resolve the Cirrus LGD-54XX "bitblt" heap overflow (CVE-2007-1320)
Jan Niehusmann discovered that the upstream fix for the CVE-2007-1320 is incomplete and still allows local users to cause a heap-based buffer overlow, when connecting via the VNC console.
Steps to reproduce:
No reproducer.
Upstream qemu patch for the initial CVE-2007-1320 issue: https://svn.pardus.org.tr/pardus/2007/applications/emulators/qemu/files/CVE-2007-1320.patch
Proposed upstream correction of this patch - see attachment.
Devin Carraway of the Debian Security Team discovered that the upstream fix for the CVE-2008-2079 is incomplete and still makes it possible for local users to create tables via INDEX/DATA DIRECTORY directives in the MySQL data directory (/var/lib/mysql) via directory symlinks.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480292#25
CVE-2008-2079 was tracked via bug bug #445222.
An attacker needs following to exploit this issue: - MySQL database account with privileges to create tables - shell access to the host running MySQL database with write access to a directory accessible by the mysqld daemon process
QEMU 0.9.0 does not properly handle changes to removable media, which allows guest OS users to read arbitrary files on the host OS by using the diskformat: parameter in the -usbdevice option to modify the disk-image header to identify a different format, a related issue to CVE-2008-2004.
Multiple buffer overflows in yaSSL 1.7.5 and earlier, as used in MySQL and possibly other products, allow remote attackers to execute arbitrary code via (1) the ProcessOldClientHello function in handshake.cpp or (2) "inputbuffer& operator>>" in yasslimp.cpp.
The http-index-format MIME type parser (nsDirIndexParser) in Firefox 3.x before 3.0.4, Firefox 2.x before 2.0.0.18, and SeaMonkey 1.x before 1.1.13 does not check for an allocation failure, which allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via an HTTP index response with a crafted 200 header, which triggers memory corruption and a buffer overflow.
Description of problem: Similar to the second issue that Fab mentioned in his presentation at 26c3, this affects the e1000e driver. See https://bugzilla.redhat.com/showbug.cgi?id=550907#c0 issue #2 for the description, and this https://bugzilla.redhat.com/showbug.cgi?id=550907#c4. This bug is filed to make sure we fix this too.
http://www.securityfocus.com/bid/37523
Description of problem: This was disclosed at 26c3.
Fabian also mentioned the fix for CVE-2009-1389 regarding the r8169 driver introduces a similar security problem as this: http://git.kernel.org/linus/fdd7b4c3302c93f6833e338903ea77245eb510b4
- RTLW16(RxMaxSize, 16383); + RTLW16(RxMaxSize, rxbufsz);
is actually a revert of this: http://git.kernel.org/linus/126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c
- / For gigabit rtl8169, MTU + header + CRC + VLAN / - RTLW16(RxMaxSize, tp->rxbufsz); + / Low hurts. Let's disable the filtering. / + RTLW16(RxMaxSize, 16383);
The accompanying comment for the original commit (126fa):
The size of the incoming frame is not correctly checked.
The RxMaxSize register (0xDA) does not work as expected and incoming frames whose size exceeds the MTU actually end spanning multiple descriptors. The first Rx descriptor contains the size of the whole frame (or some garbage in its place). The driver does not expect something above the space allocated to the current skb and crashes loudly when it issues a skbput.
The fix contains two parts: - disable hardware Rx size filtering: so far it only proved to be able to trigger some new fancy errors; [...]
warned of issues when using hardware Rx size filtering and Fabian claimed to be able to trigger something similar to the e1000 bug when using a specific packet size.
References: http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html http://blog.c22.cc/2009/12/27/26c3-cat-procsysnetipv4fuckups/ http://twitter.com/dakami/statuses/7104238406 https://bugzilla.redhat.com/CVE-2009-1389 http://www.securityfocus.com/bid/37521