kernel/linux.git, branch v2.6.16.6

Linux 2.6.16.6

2006-04-17T20:36:51+00:00

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

2006-04-17T20:16:07+00:00

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:06+00:00

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:06+00:00

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

[PATCH] USB: remove __init from usb_console_setup

2006-04-17T20:16:06+00:00

This prevents an Oops if booted with "console=ttyUSB0" but without a USB-serial dongle, and plugged one in afterwards. Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix suspend with traced tasks

2006-04-17T20:16:06+00:00

strace /bin/bash misbehaves after resume; this fixes it. (akpm: it's scary calling refrigerator() in state TASK_TRACED, but it seems to do the right thing). Signed-off-by: Pavel Machek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] Incorrect signature sent on SMB Read

2006-04-17T20:16:06+00:00

Fixes Samba bug 3621 and kernel.org bug 6147 For servers which require SMB/CIFS packet signing, we were sending the wrong signature (all zeros) on SMB Read request. The new cifs routine to do signatures across an iovec was not complete - and SMB Read, unlike the new SMBWrite2, did not fall back to the older routine (ie use SendReceive vs. the more efficient SendReceive2 ie used the older cifs_sign_smb vs. the disabled cifs_sign_smb2) for calculating signatures. This finishes up cifs_sign_smb2/cifs_calc_signature2 so that the callers of SendReceive2 can get SMB/CIFS packet signatures. Now that cifs_sign_smb2 is supported, we could start using it in the write path but this smaller fix does not include the change to use SMBWrite2 when signatures are required (which when enabled will make more Writes more efficient and alloc less memory). Currently Write2 is only used when signatures are not required at the moment but after more testing we will enable that as well). Thanks to James Slepicka and Sam Flory for initial investigation. Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman

[PATCH] RLIMIT_CPU: fix handling of a zero limit

2006-04-17T20:16:06+00:00

At present the kernel doesn't honour an attempt to set RLIMIT_CPU to zero seconds. But the spec says it should, and that's what 2.4.x does. Fixing this for real would involve some complexity (such as adding a new it-has-been-set flag to the task_struct, and testing that everwhere, instead of overloading the value of it_prof_expires). Given that a 2.4 kernel won't actually send the signal until one second has expired anyway, let's just handle this case by treating the caller's zero-seconds as one second. Cc: Martin Schwidefsky Cc: Ulrich Weigand Cc: Cliff Wickman Acked-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix utime(2) in the case that no times parameter was passed in.

2006-04-17T20:16:06+00:00

SGI-PV: 949858 SGI-Modid: xfs-linux-melb:xfs-kern:25717a Signed-off-by: Jes Sorensen Signed-off-by: Nathan Scott

[PATCH] alpha: SMP boot fixes

2006-04-17T20:16:06+00:00

I've encountered two problems with 2.6.16 and newer kernels on my API CS20 (dual 833MHz Alpha 21264b processors). The first is the kernel OOPSing because of a NULL pointer dereference while trying to populate SysFS with the CPU information. The other is that only one processor was being brought up. I've included a small Alpha-specific patch that fixes both problems. The first problem was caused by the CPUs never being properly registered using register_cpu(), the way it's done on other architectures. The second problem has to do with the removal of hwrpb_cpu_present_mask in arch/alpha/kernel/smp.c. In setup_smp() in the 2.6.15 kernel sources, hwrpb_cpu_present_mask has a bit set for each processor that is probed, and afterwards cpu_present_mask is set to the cpumask for the boot CPU. In the same function of the same file in the 2.6.16 sources, instead of hwrpb_cpu_present_mask being set, cpu_possible_map is updated for each probed CPU. cpu_present_mask is still set to the cpumask of the boot CPU afterwards. The problem lies in include/asm-alpha/smp.h, where cpu_possible_map is #define'd to be cpu_present_mask. Cleanups from: Ivan Kokshaysky - cpu_present_mask and cpu_possible_map are essentially the same thing on alpha, as it doesn't support CPU hotplug; - allocate "struct cpu" only for present CPUs, like sparc64 does. Static array of "struct cpu" is just a waste of memory. Signed-off-by: Brian Uhrain Cc: Richard Henderson Cc: Ivan Kokshaysky Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman