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: 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: 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: sctppacketconfig() is called when getting the packet ready for appending of chunks. The function should not touch the current state, since it's possible to ping-pong between two transports when sending, and that can result packet corruption followed by skb overlfow crash.

Upstream commit: http://git.kernel.org/linus/4bdab43323b459900578b200a4b8cf9713ac8fab

Reference: http://marc.info/?l=linux-netdev&m=128453869227715&w=3 http://www.spinics.net/lists/linux-sctp/msg01051.html

Essentially, we are resetting the contents of the packet when it's not empty.

Description of problem: CVE-2007-4573 regression

Reintroduced in v2.6.27-rc1 via commit d4d67150.

Upstream commits: http://git.kernel.org/linus/36d001c70d8a0144ac1d038f6876c484849a74de http://git.kernel.org/linus/eefdca043e8391dcd719711716492063030b55ac

References: http://sota.gen.nz/compat2/

Acknowledgements:

Red Hat would like to thank Ben Hawkes for reporting this issue.

Integer overflow in the rdsrdmapages function in net/rds/rdma.c in the Linux kernel allows local users to cause a denial of service (crash) and possibly execute arbitrary code via a crafted iovec struct in a Reliable Datagram Sockets (RDS) request, which triggers a buffer overflow.

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.