user/sven/linux.git, branch v2.6.16.9

Linux 2.6.16.9

2006-04-19T06:10:14Z

[PATCH] i386/x86-64: Fix x87 information leak between processes (CVE-2006-1056)

2006-04-19T05:54:44Z

AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE when an exception is pending. This means the value leak through context switches and allow processes to observe some x87 instruction state of other processes. This was actually documented by AMD, but nobody recognized it as being different from Intel before. The fix first adds an optimization: instead of unconditionally calling FNCLEX after each FXSAVE test if ES is pending and skip it when not needed. Then do a x87 load from a kernel variable to clear FOP/FIP/FDP. This means other processes always will only see a constant value defined by the kernel in their FP state. I took some pain to make sure to chose a variable that's already in L1 during context switch to make the overhead of this low. Also alternative() is used to patch away the new code on CPUs who don't need it. Patch for both i386/x86-64. The problem was discovered originally by Jan Beulich. Richard Brunner provided the basic code for the workarounds, with contribution from Jan. This is CVE-2006-1056 Cc: richard.brunner@amd.com Cc: jbeulich@novell.com Signed-off-by: Andi Kleen Signed-off-by: Greg Kroah-Hartman

Linux 2.6.16.8

2006-04-18T21:32:07Z

[PATCH] ip_route_input panic fix (CVE-2006-1525)

2006-04-18T21:31:47Z

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=6388 The bug is caused by ip_route_input dereferencing skb->nh.protocol of the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing it). It only happens if the route requested is for a multicast IP address. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Linux 2.6.16.7

2006-04-17T21:53:25Z

[PATCH] fix MADV_REMOVE vulnerability (CVE-2006-1524 for real this time)

2006-04-17T21:52:57Z

madvise_remove needs to respect file and mmap protections. Signed-off-by: Hugh Dickins Signed-off-by: Greg Kroah-Hartman

Linux 2.6.16.6

2006-04-17T20:36:51Z

[PATCH] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524)

2006-04-17T20:16:07Z

I found that all of 2.4 and 2.6 have been letting mprotect give write permission to a readonly attachment of shared memory, whether or not IPC would give the caller that permission. SUS says "The behaviour of this function [mprotect] is unspecified if the mapping was not established by a call to mmap", but I don't think we can interpret that as allowing it to subvert IPC permissions. I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and the patch below reproduces that behaviour - mprotect cannot be used to add write permission to a shared memory segment attached readonly. This patch is simple, and I'm sure it's what we should have done in 2.4.0: if you want to go on to switch write permission on and off with mprotect, just don't attach the segment readonly in the first place. However, we could have accumulated apps which attach readonly (even though they would be permitted to attach read/write), and which subsequently use mprotect to switch write permission on and off: it's not unreasonable. I was going to add a second ipcperms check in do_shmat, to check for writable when readonly, and if not writable find_vma and clear VM_MAYWRITE. But security_ipc_permission might do auditing, and it seems wrong to report an attempt for write permission when there has been none. Or we could flag the vma as SHM, note the shmid or shp in vm_private_data, and then get mprotect to check. But the patch below is a lot simpler: I'd rather stick with it, if we can convince ourselves somehow that it'll be safe. Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

[PATCH] atm: clip causes unregister hang

2006-04-17T20:16:06Z

If Classical IP over ATM module is loaded, its neighbor table gets populated when permanent neighbor entries are created; but these entries are not flushed when the device is removed. Since the entry never gets flushed the unregister of the network device never completes. This version of the patch also adds locking around the reference to the atm arp daemon to avoid races with events and daemon state changes. (Note: barrier() was never really safe) Bug-reference: http://bugzilla.kernel.org/show_bug.cgi?id=6295 Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman

[PATCH] fix non-leader exec under ptrace

2006-04-17T20:16:06Z

This reverts most of commit 30e0fca6c1d7d26f3f2daa4dd2b12c51dadc778a. It broke the case of non-leader MT exec when ptraced. I think the bug it was intended to fix was already addressed by commit 788e05a67c343fa22f2ae1d3ca264e7f15c25eaf. Signed-off-by: Roland McGrath Signed-off-by: Greg Kroah-Hartman