Use-after-free vulnerability in WebCore in WebKit in Google Chrome before 5.0.375.70 allows remote attackers to cause a denial of service (memory corruption) or possibly execute arbitrary code via vectors involving remote fonts in conjunction with shadow DOM trees, aka rdar problem 8007953. NOTE: this might overlap CVE-2010-1771.

Marc Schoenefeld found a flaw in the way OpenOffice.org 3.2.0 and earlier, enforced non-executable permission, when browsing macros, written in Python scripting language. If a local user was tricked into opening a specially-crafted OpenDocument Text (ODT) file, containing macros, and previewed the macro directories structure, it could lead to Python macro execution even when macros execution was disabled.

rendering/FixedTableLayout.cpp in WebCore in WebKit in Google Chrome before 5.0.375.70 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via an HTML document that has a large colspan attribute within a table.

Description of problem: On parsing malformed X.25 facilities, decrementing the remaining length may cause it to underflow. Since the length is an unsigned integer, this will result in the loop continuing until the kernel crashes.

This patch adds checks to ensure decrementing the remaining length does not cause it to wrap around.

http://marc.info/?l=linux-netdev&m=128951543005554&w=2

Acknowledgements:

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

Statement:

This issue did not affect the versions of Linux kernel as shipped with Red Hat Enterprise Linux 4, 5, 6 and Red Hat Enterprise MRG as they did not include support for CCITT X.25 Packet Layer.

Quoting from the upstream commit: Almost all r128's private ioctls require that the CCE state has already been initialised. However, most do not test that this has been done, and will proceed to dereference a null pointer. This may result in a security vulnerability, since some ioctls are unprivileged.

This adds a macro for the common initialisation test and changes all ioctl implementations that require prior initialisation to use that macro.

Also, r128doinitcce() does not test that the CCE state has not been initialised already. Repeated initialisation may lead to a crash or resource leak. This adds that test.

http://git.kernel.org/linus/7dc482dfeeeefcfd000d4271c4626937406756d7

Other references: http://secunia.com/advisories/36707/

Array index error in the gdthreadevent function in drivers/scsi/gdth.c in the Linux kernel before 2.6.32-rc8 allows local users to cause a denial of service or possibly gain privileges via a negative event index in an IOCTL request.

Memory leak in the appletalk subsystem in the Linux kernel 2.4.x through 2.4.37.6 and 2.6.x through 2.6.31, when the appletalk and ipddp modules are loaded but the ipddp"N" device is not found, allows remote attackers to cause a denial of service (memory consumption) via IP-DDP datagrams.

The pollmodeio file for the megaraidsas driver in the Linux kernel 2.6.31.6 and earlier has world-writable permissions, which allows local users to change the I/O mode of the driver by modifying this file.

Description of problem: Both PPPoL2TP (in net/l2tp/l2tpppp.c, pppol2tpsendmsg()) and IPoL2TP (in net/l2tp/l2tpip.c, l2tpipsendmsg()) make calls to sockwmalloc() that perform arithmetic on the size argument without any maximum bound. As a result, by issuing sendto() calls with very large sizes, this allocation size will wrap and result in a small buffer being allocated, leading to ugliness immediately after (probably kernel panics due to bad skbuff tail position, but possibly kernel heap corruption).

Reference: http://www.spinics.net/lists/netdev/msg145673.html

Acknowledgements:

Red Hat would like to thank Dan Rosenberg 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: The PKTCTRLCMDSTATUS device ioctl retrieves a pointer to a pktcdvddevice from the global pktdevs array. The index into this array is provided directly by the user and is a signed integer, so the comparison to ensure that it falls within the bounds of this array will fail when provided with a negative index.

This can be used to read arbitrary kernel memory or cause a crash due to an invalid pointer dereference. This can be exploited by users with permission to open /dev/pktcdvd/control (on many distributions, this is readable by group "cdrom").

Upstream commit: http://git.kernel.org/linus/252a52aa4fa22a668f019e55b3aac3ff71ec1c29

Last updated 24 July 2024

Description of problem: gdthioctlalloc() takes the size variable as an int. copyfromuser() takes the size variable as an unsigned long. gen.datalen and gen.senselen are unsigned longs. On x8664 longs are 64 bit and ints are 32 bit.

We could pass in a very large number and the allocation would truncate the size to 32 bits and allocate a small buffer. Then when we do the copyfromuser(), it would result in a memory corruption.

Reference: http://ns3.spinics.net/lists/linux-scsi/msg47361.html

Upstream: http://git.kernel.org/linus/f63ae56e4e97fb12053590e41a4fa59e7daa74a4

net/unix/afunix.c in the Linux kernel 2.6.31.4 and earlier allows local users to cause a denial of service (system hang) by creating an abstract-namespace AFUNIX listening socket, performing a shutdown operation on this socket, and then performing a series of connect operations to this socket.

The modproxyftp module in the Apache HTTP Server allows remote attackers to bypass intended access restrictions and send arbitrary commands to an FTP server via vectors related to the embedding of these commands in the Authorization HTTP header, as demonstrated by a certain module in VulnDisco Pack Professional 8.11. NOTE: as of 20090903, this disclosure has no actionable information. However, because the VulnDisco Pack author is a reliable researcher, the issue is being assigned a CVE identifier for tracking purposes.

References: http://intevydis.com/vd-list.shtml

Description of problem: This doesn't look correct, the iosubmit systemcall calls doiosubmit() directly:

SYSCALLDEFINE3(iosubmit, aiocontextt, ctxid, long, nr, struct iocb user user , iocbpp) { return doiosubmit(ctxid, nr, iocbpp, 0); }

doiosubmit only checks if nr < 0, but doesnt check if the accessok multiplication will overflow.

long doiosubmit(aiocontextt ctxid, long nr, struct iocb user user iocbpp, bool compat) { ... if (unlikely(!accessok(VERIFYREAD, iocbpp, (nrsizeof(iocbpp))))) return -EFAULT; ...

Then it uses this loop with getusernocheck(), which doesn't look safe.

... for (i=0; i<nr; i++) { struct iocb user useriocb; struct iocb tmp;

if (unlikely(getuser(useriocb, iocbpp + i))) { ret = -EFAULT; break; } ...

Acknowledgements:

Red Hat would like to thank Tavis Ormandy for reporting this issue.

Due to integer underflow and overflow issues when determining the number of pages required for maliciously crafted I/O requests, a local user could send a device ioctl that results in the sequential allocation of a very large number of pages, causing the OOM killer to be invoked and crashing the system:

Proposed patch: http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commit;h=cb4644cac4a2797afc847e6c92736664d4b0ea34

Acknowledgements:

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

Last updated 24 July 2024

Description of problem: The sndctlnew() function in sound/core/control.c allocates space for a sndkcontrol struct by performing arithmetic operations on a user-provided size without checking for integer overflow. If a user provides a large enough size, an overflow will occur, the allocated chunk will be too small, and a second user-influenced value will be written repeatedly past the bounds of this chunk. This code is reachable by unprivileged users who have permission to open a /dev/snd/controlC device (on many distros, this is group "audio") via the SNDRVCTLIOCTLELEMADD and SNDRVCTLIOCTLELEMREPLACE ioctls.

Upstream commit: http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commitdiff;h=5591bf07225523600450edd9e6ad258bb877b779

Acknowledgements:

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

OpenSSL before 0.9.8q, and 1.0.x before 1.0.0c, when SSLOPNETSCAPEREUSECIPHERCHANGEBUG is enabled, does not properly prevent modification of the ciphersuite in the session cache, which allows remote attackers to force the downgrade to an unintended cipher via vectors involving sniffing network traffic to discover a session identifier.

Cross-site scripting (XSS) vulnerability in editing/markup.cpp in WebCore in WebKit in Google Chrome before 5.0.375.70 allows remote attackers to inject arbitrary web script or HTML via vectors related to the node.innerHTML property of a TEXTAREA element. NOTE: this might overlap CVE-2010-1762.

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 "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.

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

Quote from http://patchwork.ozlabs.org/patch/35412/: Commit 9ef1d4c7c7aca1cd436612b6ca785b726ffb8ed8 introduced a typo in initialization.

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 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.