Adobe Flash Player contains a memory corruption vulnerability that allows for remote code execution or denial-of-service (DoS).

Last updated 24 July 2024

The modifyresolvconfsuse script in the vpnc package before 0.5.1-55.10.1 in SUSE Linux Enterprise Desktop 11 SP1 might allow remote attackers to execute arbitrary commands via a crafted DNS domain name.

Adobe Flash Player before 10.2.154.27 on Windows, Mac OS X, Linux, and Solaris and 10.2.156.12 and earlier on Android; Adobe AIR before 2.6.19140; and Authplay.dll (aka AuthPlayLib.bundle) in Adobe Reader 9.x before 9.4.4 and 10.x through 10.0.1 on Windows, Adobe Reader 9.x before 9.4.4 and 10.x before 10.0.3 on Mac OS X, and Adobe Acrobat 9.x before 9.4.4 and 10.x before 10.0.3 on Windows and Mac OS X allow remote attackers to execute arbitrary code or cause a denial of service (application crash) via crafted Flash content; as demonstrated by a Microsoft Office document with an embedded .swf file that has a size inconsistency in a "group of included constants," object type confusion, ActionScript that adds custom functions to prototypes, and Date objects; and as exploited in the wild in April 2011.

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.

Description of problem: The handling functions for sending and receiving messages, in rdspagecopyuser(), use the unchecked copyuserinatomic functions without any access checks on user-provided pointers. As a result, by passing a kernel address as an iovec base address in recvmsg-style calls, a local user can overwrite arbitrary kernel memory, which can easily be used to escalate privileges to root.

Introduced via 7875e18e (v2.6.30-rc1).

Acknowledgements:

Red Hat would like to thank Dan Rosenberg of Virtual Security Research for reporting this issue.

Description of problem: Kees found a flaw in the i915 GEM ioctl interface that does not check destination addresses during memory copies, allowing arbitrary memory writes into the kernel. The flaws are in drivers/gpu/drm/i915/i915gem.c in i915gempreadioctl() and i915gempwriteioctl(), which do no accessok() checks on args->dataptr. (Actually, there is one check path: i915gemgttpwritefast() does the check, but none of the other helpers do.).

Acknowledgements:

Red Hat would like to thank Kees Cook for reporting this issue.

Description of problem: There is a bug in sndseqossopen from sound/core/seq/oss/seqossinit.c. So here's the error path for some setup failure:

error: sndseqosswriteqdelete(dp->writeq); sndseqossreadqdelete(dp->readq); sndseqosssynthcleanup(dp); sndseqossmidicleanup(dp); deleteport(dp); deleteseqqueue(dp->queue); kfree(dp);

This looks okay, but actually, deleteport calls portdelete (eventually... this code is tough to follow) which does a freedevinfo on the owner struct seqossdevinfo, here (around ~269 in seqports.c):

if (port->privatefree) port->privatefree(port->privatedata);

because of this (around ~334 in seqossinit.c):

memset(&callback, 0, sizeof(callback)); callback.owner = THISMODULE; callback.privatedata = dp; callback.eventinput = sndseqosseventinput; callback.privatefree = freedevinfo; port.kernel = &callback;

Which does this:

static void freedevinfo(void private) { struct seqossdevinfo dp = (struct seqossdevinfo )private;

if (dp->timer) sndseqosstimerdelete(dp->timer); if (dp->writeq) sndseqosswriteqdelete(dp->writeq);

if (dp->readq) sndseqossreadqdelete(dp->readq); kfree(dp); }

So.....

deleteport(dp); deleteseqqueue(dp->queue); <= Oops, dereferencing released pointer. kfree(dp); <= Oops, double free.

Acknowledgements:

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

Description of problem: Discovered by Ben Hawkes, this patch adds a limit for nframes as the number of frames in TXSETUP and RXSETUP are derived from a single byte multiplex value by default. Use-cases that would require to send/filter more than 256 CAN frames should be implemented in userspace for complexity reasons anyway. Additionally the assignments of unsigned values from userspace to signed values in kernelspace and vice versa are fixed by using unsigned values in kernelspace consistently.

Upstream commit: http://git.kernel.org/linus/5b75c4973ce779520b9d1e392483207d6f842cde

Description of problem: 1. CVE-2010-2537 - The BTRFSIOCCLONE and BTRFSIOCCLONERANGE ioctls should check whether the donor file is append-only before writing to it.

2. CVE-2010-2538 - The BTRFSIOCCLONERANGE ioctl appears to have an integer overflow that allows a user to specify an out-of-bounds range to copy from the source file (if off + len wraps around).

Upstream commit: http://git.kernel.org/linus/2ebc3464781ad24474abcbd2274e6254689853b5

Reference: https://btrfs.wiki.kernel.org/index.php/MainPage

The kernel in Red Hat Enterprise Linux 6 has support for Btrfs by default.

Description of problem: CIFS has the ability to chase MS-DFS referrals. In order to do this it has to be able to resolve hostnames into IP addresses. For this, it uses the keys API to upcall to the cifs.upcall userspace helper. It then resolves the name and hands the address back to the kernel.

The dnsresolver upcall currently used by CIFS is susceptible to cache stuffing. It's possible for a malicious user to stuff the keyring with the results of a lookup, and then trick the server into mounting a server of his choosing.

Description of problem: On a 32-bit machine, info.rulecnt >= 0x40000000 leads to integer overflow and the buffer may be smaller than needed. Since ETHTOOLGRXCLSRLALL is unprivileged, this can presumably be used for at least denial of service.

Reference: http://thread.gmane.org/gmane.linux.network/164869