From Clement Lecigne: In function sockgetsockopt() located in net/core/sock.c, optval v.val is not correctly initialized and directly returned in userland in case we have SOBSDCOMPAT option set.
This dummy code should trigger the bug:
int main(void) { unsigned char buf[4] = { 0, 0, 0, 0 }; int len; int sock; sock = socket(33, 2, 2); getsockopt(sock, 1, SOBSDCOMPAT, &buf, &len); printf("%x%x%x%x\n", buf[0], buf[1], buf[2], buf[3]); close(sock); }
References: http://lkml.org/lkml/2009/2/11/374 http://lkml.org/lkml/2009/2/12/123 http://patchwork.kernel.org/patch/6816/
Fix inverted logic in skfpioctl(). Non-privileged users should not be able to clear the driver statistics.
diff --git a/drivers/net/skfp/skfddi.c b/drivers/net/skfp/skfddi.c index 607efea..9a00e55 100644 --- a/drivers/net/skfp/skfddi.c +++ b/drivers/net/skfp/skfddi.c @@ -1003,9 +1003,9 @@ static int skfpioctl(struct netdevice dev, struct ifreq rq, int cmd) break; case SKFPCLRSTATS: / Zero out the driver statistics / if (!capable(CAPNETADMIN)) { - memset(&lp->MacStat, 0, sizeof(lp->MacStat)); - } else { status = -EPERM; + } else { + memset(&lp->MacStat, 0, sizeof(lp->MacStat)); } break; default:
From Chris Evans:
It's a relatively minor signal issue where a child can send its parent process an arbitrary signal, even if the parent has a totally separate real and effective user id. This could be a nuisance in the case where long-running root daemons spawn direct child processes owned by untrusted users []. There may even be worse consequences if privileged processes have weak signal handling code for signals not normally triggerable by untrusted users.
Description of problem: If the owner of a PI futex dies we fix up the pistate and set pistate->owner to NULL. When a malicious or just sloppy programmed user space application sets the futex value to 0 e.g. by calling pthreadmutexinit(), then the futex can be acquired again. A new waiter manages to enqueue itself on the pistate w/o damage, but on unlock the kernel dereferences pistate->owner and oopses. Prevent this by checking pistate->owner in the unlock path. If pistate->owner is not current we know that user space manipulated the futex value. Ignore the mess and return -EINVAL. This catches the above case and also the case where a task hijacks the futex by setting the tid value and then tries to unlock it.
Upstream commit: http://git.kernel.org/linus/51246bfd189064079c54421507236fd2723b18f3
Note that pi-futex was introduced in: http://git.kernel.org/linus/c87e2837be82df479a6bae9f155c43516d2feebc
Description of problem: procoomscore(task) has a reference to taskstruct, but that is all. If this task was already released before we take tasklistlock - we can't use task->groupleader, it points to nowhere - it is not safe to call badness() even if this task is ->groupleader, hasintersectsmemsallowed() assumes it is safe to iterate over ->threadgroup list. - even worse, badness() can hit ->signal == NULL Add the pidalive() check to ensure unhashprocess() was not called. Also, use "task" instead of task->groupleader. badness() should return the same result for any sub-thread. Currently this is not true, but this should be changed anyway.
Upstream commit: http://git.kernel.org/linus/b95c35e76b29ba812e5dabdd91592e25ec640e93
Description of problem: knfsd crashes if you are using it to export shmemfs objects and run strict overcommit. In this situation the current->mm based modifier to the overcommit goes through a NULL pointer. We could simply check for NULL and skip the modifier but we've caught other real bugs in the past from mm being NULL here - cases where we did need a valid mm set up (eg the exec bug in 2005). To preserve the checks and get the logic we want shuffle the checking around and add a new helper to the vm security wrappers Also fix a current->mm reference in nommu that should use the passed mm
Upstream commit: nfsd: fix vm overcommit crash http://git.kernel.org/linus/731572d39fcd3498702eda4600db4c43d51e0b26 nfsd: fix vm overcommit crash fix #2 http://git.kernel.org/linus/1b79cd04fab80be61dcd2732e2423aafde9a4c1c
Reference: [PATCH] knfsd: add nfs-export support to tmpfs http://git.kernel.org/linus/91828a405ae454a9503c41a7744f6ff877a80714
The seqfile handling (ip6flgetn function in ip6flowlabel.c) in Linux kernel 2.6 up to 2.6.18-stable allows local users to cause a denial of service (hang or oops) via unspecified manipulations that trigger an infinite loop while searching for flowlabels.
Race condition in the findgetblockslow function in the ISO9660 filesystem in Linux 2.6.18 and possibly other versions allows local users to cause a denial of service (infinite loop) by mounting a crafted ISO9660 filesystem containing malformed data structures.
The copyfromuser function in the uaccess code in Linux kernel 2.6 before 2.6.19-rc1, when running on s390, does not properly clear a kernel buffer, which allows local user space programs to read portions of kernel memory by "appending to a file from a bad address," which triggers a fault that prevents the unused memory from being cleared in the kernel buffer.
The blockpreparewrite function in fs/buffer.c for Linux kernel 2.6.x before 2.6.13 does not properly clear buffers during certain error conditions, which allows local users to read portions of files that have been unlinked.
cryptoloop on Linux kernel 2.6.x, when used on certain file systems with a block size 1024 or greater, has certain "IV computation" weaknesses that allow watermarked files to be detected without decryption.
Buffer overflow in sysctl in the Linux Kernel 2.6 before 2.6.15 allows local users to corrupt user memory and possibly cause a denial of service via a long string, which causes sysctl to write a zero byte outside the buffer. NOTE: since the sysctl is called from a userland program that provides the argument, this might not be a vulnerability, unless a legitimate user-assisted or setuid scenario can be identified.
The securelevels implementation in NetBSD 2.1 and earlier, and Linux 2.6.15 and earlier, allows local users to bypass time setting restrictions and set the clock backwards by setting the clock ahead to the maximum unixtime value (19 Jan 2038), which then wraps around to the minimum value (13 Dec 1901), which can then be set ahead to the desired time, aka "settimeofday() time wrap."
The NAT code (1) ipnatprototcp.c and (2) ipnatprotoudp.c in Linux kernel 2.6 before 2.6.13 and 2.4 before 2.4.32-rc1 incorrectly declares a variable to be static, which allows remote attackers to cause a denial of service (memory corruption) by causing two packets for the same protocol to be NATed at the same time, which leads to memory corruption.
The sysgetthreadarea function in process.c in Linux 2.6 before 2.6.12.4 and 2.6.13 does not clear a data structure before copying it to userspace, which might allow a user process to obtain sensitive information.
drm.c in Linux kernel 2.6.10 to 2.6.13 creates a debug file in sysfs with world-readable and world-writable permissions, which allows local users to enable DRM debugging and obtain sensitive information.
The audit system in Linux kernel 2.6.6, and other versions before 2.6.13.4, when CONFIGAUDITSYSCALL is enabled, uses an incorrect function to free namescache memory, which prevents the memory from being tracked by AUDITSYSCALL code and leads to a memory leak that allows attackers to cause a denial of service (memory consumption).
Memory leak in the requestkeyauthdestroy function in requestkeyauth in Linux kernel 2.6.10 up to 2.6.13 allows local users to cause a denial of service (memory consumption) via a large number of authorization token keys.
Linux kernel 2.6.8 to 2.6.14-rc2 allows local users to cause a denial of service (kernel OOPS) via a userspace process that issues a USB Request Block (URB) to a USB device and terminates before the URB is finished, which leads to a stale pointer reference.
Multiple vulnerabilities in Linux kernel before 2.6.13.2 allow local users to cause a denial of service (kernel OOPS from null dereference) via (1) fput in a 32-bit ioctl on 64-bit x86 systems or (2) sockfdput in the 32-bit routingioctl function on 64-bit systems.
The udpv6getport function in udp.c in Linux 2.6 before 2.6.14-rc5, when running IPv6, allows local users to cause a denial of service (infinite loop and crash).
The iptrecent kernel module (iptrecent.c) in Linux kernel 2.6.12 and earlier does not properly perform certain time tests when the jiffies value is greater than LONGMAX, which can cause iptrecent netfilter rules to block too early, a different vulnerability than CVE-2005-2872.
The rawsendmsg function in the Linux kernel 2.6 before 2.6.13.1 allows local users to cause a denial of service (change hardware state) or read from arbitrary memory via crafted input.
The Linux kernel 2.6 before 2.6.12.1 allows local users to cause a denial of service (kernel panic) via a non group-leader thread executing a different program than was pending in itimer, which causes the signal to be delivered to the old group-leader task, which does not exist.
The keyuserlookup function in security/keys/key.c in Linux kernel 2.6.10 to 2.6.11.8 may allow attackers to cause a denial of service (oops) via SMP.
Multiple integer signedness errors in the sgscsiioctl function in scsiioctl.c for Linux 2.6.x allow local users to read or modify kernel memory via negative integers in arguments to the scsi ioctl, which bypass a maximum length check before calling the copyfromuser and copytouser functions.
Linux kernel 2.4.x and 2.6.x allows local users to cause a denial of service (CPU and memory consumption) and bypass RLIMMEMLOCK limits via the mlockall call.
Linux kernel 2.4.x and 2.6.x up to 2.6.16 allows local users to bypass IPC permissions and modify a readonly attachment of shared memory by using mprotect to give write permission to the attachment. NOTE: some original raw sources combined this issue with CVE-2006-1524, but they are different bugs.
choosenewparent in Linux kernel before 2.6.11.12 includes certain debugging code, which allows local users to cause a denial of service (panic) by causing certain circumstances involving termination of a parent process.
The Linux kernel before 2.6.16.9 and the FreeBSD kernel, when running on AMD64 and other 7th and 8th generation AuthenticAMD processors, only save/restore the FOP, FIP, and FDP x87 registers in FXSAVE/FXRSTOR when an exception is pending, which allows one process to determine portions of the state of floating point instructions of other processes, which can be leveraged to obtain sensitive information such as cryptographic keys. NOTE: this is the documented behavior of AMD64 processors, but it is inconsistent with Intel processors in a security-relevant fashion that was not addressed by the kernels.