Last updated 29 November 2024
A flaw was found in the way pppol2tpsetsockopt() and pppol2tpgetsockopt() functions in the Linux kernel's PPP over L2TP implementation handled non-SOLPPPOL2TP level.
A local, unprivileged user could use this flaw to escalate their privileges on the system.
Acknowledgements:
Red Hat would like to thank Sasha Levin for reporting this issue.
Reported by Tavis Ormandy of Google Security Team. The root cause was determined to be a use-after-free of locked async file descriptors, and it is believed to have been introduced here: http://git.kernel.org/linus/233e70f4228e78eb2f80dc6650f65d3ae3dbf17c
Acknowledgements:
Red Hat would like to thank Tavis Ormandy of Google Security Team for reporting this issue.
Description of problem: commit dce766af541f6605fa9889892c0280bab31c66ab Author: Florian Westphal <fwestphal> Date: Fri Jan 8 17:31:24 2010 +0100
netfilter: ebtables: enforce CAPNETADMIN normal users are currently allowed to set/modify ebtables rules. Restrict it to processes with CAPNETADMIN. Note that this cannot be reproduced with unmodified ebtables binary because it uses SOCKRAW. Signed-off-by: Florian Westphal <fwestphal> Cc: stable Signed-off-by: Patrick McHardy <kaber>
Upstream commit: http://git.kernel.org/linus/dce766af541f6605fa9889892c0280bab31c66ab
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.
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.
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
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.
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.
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.
A new system call named vmsplice() was introduced in the 2.6.17 release of the Linux kernel.
COSEINC reported two issues affecting vmsplice, CVE-2008-0009 and CVE-2008-0010.
On Saturday 20080210 a public exploit was released that utilised a similar flaw in vmsplice (vmsplicetopipe function) to allow a local user to gain privileges on some architectures.
See also http://marc.info/?t=120263655300003&r=1&w=2
This issue will affect kernels 2.6.17+ and therefore affected Red Hat Enterprise Linux 5, but not Red Hat Enterprise Linux 4, 3, or 2.1.
VFS in the Linux kernel before 2.6.22.16, and 2.6.23.x before 2.6.23.14, performs tests of access mode by using the flag variable instead of the accmode variable, which might allow local users to bypass intended permissions and remove directories.