Last updated 24 July 2024
The pariscshowstack function in arch/parisc/kernel/traps.c in the Linux kernel before 2.6.28-rc7 on PA-RISC allows local users to cause a denial of service (system crash) via vectors associated with an attempt to unwind a stack that contains userspace addresses.
http://marc.info/?l=linux-netdev&m=122593044330973&w=2
"The following code causes a kernel panic on Linux 2.6.26: http://darkircop.org/unix.c
I haven't investigated the bug so I'm not sure what is causing it, and don't know if it's exploitable. The code passes unix sockets from one process to another using unix sockets. The bug probably has to do with closing file descriptors."
net/atm/svc.c in the ATM subsystem in the Linux kernel 2.6.27.8 and earlier allows local users to cause a denial of service (kernel infinite loop) by making two calls to svclisten for the same socket, and then reading a /proc/net/atm/vc file, related to corruption of the vcc table.
The inotify functionality in Linux kernel 2.6 before 2.6.28-rc5 might allow local users to gain privileges via unknown vectors related to race conditions in inotify watch removal and umount.
Buffer overflow in the lbsprocessbss function in drivers/net/wireless/libertas/scan.c in the libertas subsystem in the Linux kernel before 2.6.27.5 allows remote attackers to have an unknown impact via an "invalid beacon/probe response."
From: Eric Sesterhenn: Fix a stack corruption caused by a corrupted hfs filesystem. If the catalog name length is corrupted the memcpy overwrites the catalog btree structure. Since the field is limited to HFSNAMELEN bytes in the structure and the file format, we throw an error if it is too long.
Buffer overflow in the hfsplusfindcat function in fs/hfsplus/catalog.c in the Linux kernel before 2.6.28-rc1 allows attackers to cause a denial of service (memory corruption or system crash) via an hfsplus filesystem image with an invalid catalog namelength field, related to the hfspluscatbuildkeyuni function.
The Stream Control Transmission Protocol (sctp) implementation in the Linux kernel before 2.6.27 does not properly handle a protocol violation in which a parameter has an invalid length, which allows attackers to cause a denial of service (panic) via unspecified vectors, related to sctpsfviolationparamlen, sctpsfabortviolation, sctpmakeabortviolation, and incorrect data types in function calls.
sctp in Linux kernel before 2.6.25.18 allows remote attackers to cause a denial of service (OOPS) via an INIT-ACK that states the peer does not support AUTH, which causes the sctpprocessinit function to clean up active transports and triggers the OOPS when the T1-Init timer expires.
The TCP implementation in (1) Linux, (2) platforms based on BSD Unix, (3) Microsoft Windows, (4) Cisco products, and probably other operating systems allows remote attackers to cause a denial of service (connection queue exhaustion) via multiple vectors that manipulate information in the TCP state table, as demonstrated by sockstress.
The sctpauthepsethmacs function in net/sctp/auth.c in the Stream Control Transmission Protocol (sctp) implementation in the Linux kernel before 2.6.26.4, when the SCTP-AUTH extension is enabled, does not verify that the identifier index is within the bounds established by SCTPAUTHHMACIDMAX, which allows local users to obtain sensitive information via a crafted SCTPHMACIDENT IOCTL request involving the sctpgetsockopt function, a different vulnerability than CVE-2008-4113.
Description of problem: Miklos Szeredi reported that splice() to files opened with OAPPEND are ignored, which allows users to bypass the append-only restriction.
Description of problem: If addtopagecachelru() fails, the page will not be locked. But splice jumps to an error path that does a page release and unlock, causing a BUG() in unlockpage().
Race condition in the dosetlk function in fs/nfs/file.c in the Linux kernel before 2.6.26 allows local users to cause a denial of service (crash) via vectors resulting in an interrupted RPC call that leads to a stray FLPOSIX lock, related to improper handling of a race between fcntl and close in the EINTR case.
Description of problem: When creating a file, open()/creat() allows the setgid bit to be set via the mode argument even when, due to the bsdgroups mount option or the file being created in a setgid directory, the new file's group is one which the user is not a member of. The user can then use ftruncate() and memory-mapped I/O to turn the new file into an arbitrary binary and thus gain the privileges of this group, since these operations do not clear the setgid bit.
The sctpgetsockopthmacident function in net/sctp/socket.c in the Stream Control Transmission Protocol (sctp) implementation in the Linux kernel before 2.6.26.4, when the SCTP-AUTH extension is enabled, relies on an untrusted length value to limit copying of data from kernel memory, which allows local users to obtain sensitive information via a crafted SCTPHMACIDENT IOCTL request involving the sctpgetsockopt function.
Buffer overflow in nfsd in the Linux kernel before 2.6.26.4, when NFSv4 is enabled, allows remote attackers to have an unknown impact via vectors related to decoding an NFSv4 acl.
A certain Fedora patch for the utrace subsystem in the Linux kernel before 2.6.26.5-28 on Fedora 8, and before 2.6.26.5-45 on Fedora 9, allows local users to cause a denial of service (NULL pointer dereference and system crash or hang) via a call to the utracecontrol function.
Description of problem: Originally from Mark Fasheh <mark.fasheh>
genericfilesplicewrite() does not remove SISUID or SISGID. This is inconsistent with the way we generally write to files.
Proposed upstream patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8c34e2d63231d4bf4852bac8521883944d770fe3
arch/i386/kernel/sysenter.c in the Virtual Dynamic Shared Objects (vDSO) implementation in the Linux kernel before 2.6.21 does not properly check boundaries, which allows local users to gain privileges or cause a denial of service via unspecified vectors, related to the installspecialmapping, syscall, and syscall32nopage functions.
Description of problem: Eugene Teo reported that an integer overflow flaw was found in the Linux kernel dccpsetsockoptchange() function. The vulnerability exists due to a lack of sanitisation performed on a user-controlled integer value before the value is employed as the size argument of a memory allocation operation. An attacker may leverage this vulnerability to trigger a kernel panic on a victim's machine remotely.
Double free vulnerability in the utrace support in the Linux kernel, probably 2.6.18, in Red Hat Enterprise Linux (RHEL) 5 and Fedora Core 6 (FC6) allows local users to cause a denial of service (oops), as demonstrated by a crash when running the GNU GDB testsuite, a different vulnerability than CVE-2008-2365.
The pppol2tprecvmsg function in drivers/net/pppol2tp.c in the Linux kernel 2.6 before 2.6.26-rc6 allows remote attackers to cause a denial of service (kernel heap memory corruption and system crash) and possibly have unspecified other impact via a crafted PPPOL2TP packet that results in a large value for a certain length variable.
Description of problem:
Alexei Dobryanov has reported the following kernel utrace related issue (BZ#245735):
1. late ptracemayattach() check
static int ptraceattach(struct taskstruct task) { ... engine = utraceattach(task, (UTRACEATTACHCREATE | UTRACEATTACHEXCLUSIVE | UTRACEATTACHMATCHOPS), &ptraceutraceops, 0); [error checking] if (ptracemayattach(task)) { [more attaching process]
Doing may attach check there is asking for trouble, because utraceattach() will happily create and modify "struct utrace " and create and attach engines to it on task you don't have permissions. Order should be reverted. That's easy.
2. race around &deadengineops setting...
I originally thought #1 would lead to memory leaks, however, written dumb PTRACEATTACH'er gave much more amazing results.
The following program quickly (1 sec) oopses kernel when run against process you normally can't attach to (like normal user to getty processes)
#include <stdlib.h> #include <sys/ptrace.h>
int main(int argc, char argv[]) { pidt pid = atoi(argv[1]);
while (1) ptrace(PTRACEATTACH, pid, NULL, NULL);
return 0; }
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<0000000000000000>] [<ffffffff8005f1cd>] reportquiescent+0x36/0x154 [<ffffffff8005f316>] utracequiescent+0x2b/0x238 [<ffffffff800601e9>] utracegetsignal+0x45d/0x4c0 [<ffffffff80039c6f>] getsignaltodeliver+0x169/0x47a [<ffffffff80008f5a>] donotifyresume+0xd0/0x7e2 [<ffffffff80203673>] spinunlockirqrestore+0x3f/0x45 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff801400c0>] ttyread+0x81/0xc7 [<ffffffff80202ede>] tracehardirqsonthunk+0x35/0x37 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff80009b43>] sysretsignal+0x21/0x31 [<ffffffff80009deb>] ptregscallcommon+0x67/0xac
This is a race we chatted with Roland about: http://marc.info/?l=linux-kernel&m=117863520707703&w=2
engine's flags and ops settings in utracedetach() and acting on them in reportquiescent():
utracedetach() reportquiescent() --------------- ------------------ [utrace lock held] [utrace lock is not held]
engine->flags = UTRACEEVENT(QUIESCE) | UTRACEACTIONQUIESCE;
if (engine->flags & UTRACEEVENT(QUIESCE)) REPORT(reportquiesce);
rcuassignpointer(engine->ops, &deadengineops);
At the moment of REPORT call engine's ops are still "live" ptrace ops which do not have ->reportquiesce callback. So, there will oops while calling function at NULL address. "Dead" ptrace engine ops do have dummy callback but it wasn't yet glued.
Obviously, patch #1 won't fix this.
3. Looks like nobody filed double free at utrace aka oops at rcuprocesscallbacks() against RHEL5 kernel.
It's bug https://bugzilla.redhat.com/bugzilla/showbug.cgi?id=207002 against FC6, but, hey, every utrace version has it. Test program attached. Every user can trigger it.
Description of problem:
Backport the feature length validation. Without this it's possible for rlen to ovelflow to 0, causing kmalloc(0), and a heap overflow during DCCP feature reconciliation. rlen = 1 + opt->dccpoplen; rpref = kmalloc(rlen, GFPATOMIC); memcpy(&rpref[1], opt->dccpopval, opt->dccpoplen); Thanks to Brandon Edwards of McAfee Avert labs for discovering this issue.
Impact:
A vulnerability exists in the DCCP implementation which can be setup and exploited by a local attacker. The vulnerability is an integer overflow which leads to a kmalloc() for 0 bytes, followed by a memory copy into the returned pointer for 255 bytes, which causes a heap overflow. This type of vulnerability can be exploited by a local attacker to gain arbitrary code execution.
Version-Release number of selected component (if applicable): 2.6.17 <= x <= 2.6.20 (See the timeline for more details)
Additional information:
This vulnerability affects the dccp kernel module (shipped as part of the RHEL kernel updates).
The (1) sparcmmapcheck function in arch/sparc/kernel/syssparc.c and the (2) sparc64mmapcheck function in arch/sparc64/kernel/syssparc.c, in the Linux kernel 2.4 before 2.4.36.5 and 2.6 before 2.6.25.3, omit some virtual-address range (aka span) checks when the mmap MAPFIXED bit is not set, which allows local users to cause a denial of service (panic) via unspecified mmap calls.
The bdxioctlpriv function in the tehuti driver (tehuti.c) in Linux kernel 2.6.x before 2.6.25.1 does not properly check certain information related to register size, which has unspecified impact and local attack vectors, probably related to reading or writing kernel memory.
Linux kernel before 2.6.25.2 does not apply a certain protection mechanism for fcntl functionality, which allows local users to (1) execute code in parallel or (2) exploit a race condition to obtain "re-ordered access to the descriptor table."
arch/s390/kernel/ptrace.c in Linux kernel 2.6.9, and other versions before 2.6.27-rc6, on s390 platforms allows local users to cause a denial of service (kernel panic) via the user-area-padding test from the ptrace testsuite in 31-bit mode, which triggers an invalid dereference.