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

Last updated 24 July 2024

Description of problem: Upstream commit dab5855 ("perfcounter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotectfixup() can free 'vma' due to merging. Fix the problem by moving perfeventmmap() hook to mprotectfixup(). In certain scenario, a local, unprivileged user could use this flaw to trigger a denial of service.

Upstream commit: http://git.kernel.org/linus/63bfd7384b119409685a17d5c58f0b56e5dc03da

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.

By submitting certain I/O requests with 0 length, a local user could cause a kernel panic.

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

Acknowledgements:

Red Hat would like to thank Dan Rosenberg 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 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: 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

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.

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

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

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.

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.

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.

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.