Contents
Changes
- Updated libata and sky2 drivers.
- Small simfs/vzdq/ubc/stats fixes.
- Mainstream bugs and security fixes.
Configs
Same as 022stab076.1 plus:
- +
CONFIG_SKY2=m - +
CONFIG_PARTITION_ADVANCED=y - +
CONFIG_EFI_PARTITION=y - +
CONFIG_OPROFILE=m
Patches
diff-ve-sched-stat-iowait-20060417
per VPS i/o wait time was accounted wrongly as presense of uninterruptible tasks, not those in IO wait state.
http://forum.openvz.org/index.php?t=tree&goto=2686&#msg_2686
diff-virtinfo-faudit-statfs
diff-simfs-statfs-20060421
Compat layer in 64bit systems didn't call faudit on statfs calls. Now faudit uses struct kstatfs for patching statfs data and compat layer uses it.
diff-ms-prio-tree-20060420
[PATCH] prio_tree: fix prio_tree_expand corner case
Currently we use prio_tree_root->index_bits to optimize the height of both the initial heap-and-radix indexed levels of a prio_tree as well as the heap-and-size indexed overflow-sub-trees. Please see the accompanying prio_tree documentation patch for further details.
When index_bits is increased in prio_tree_expand we shuffle the initial heap-and-radix indexed levels to make sure that vmas are placed in the tree at appropriate places. Similarly, since the overflow-sub-trees' heights also depend on prio_tree_root->index_bits we should shuffle all the overflow-sub-trees when index_bits changes. However, I missed to take care of this in my implementation.
Recently Stefan Hornburg (Racke) reported the problem and patiently tested the trace patches. Hugh Dickins produced the trace patches that helped to detect the bug. Moreover, Hugh reduced the crash test case to few lines of code. Thanks to both of them.
The easy fix is to disable prio_tree_expand code completely. That may lead to skewed trees in some common cases. Hence, this patch takes a different approach.
This patch fixes the problem by not optimizing the height of the overflow-sub-trees using prio_tree_root->index_bits. Now all overflow-sub-trees use full BITS_PER_LONG bits of size_index to place the vmas (that have the same start_vm_pgoff) in an overflow-sub-tree.
This may result in skewed overflow-sub-trees because all bits in vm_pgoff above prio_tree_root->index_bits will be 0 (zero). However, processes rarely map many vmas with the same start_vm_pgoff and different end_vm_pgoff. Therefore, such skewed sub-trees should be very rare.
Signed-off-by: Rajesh Venkatasubramanian <vrajesh@umich.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
http://lkml.org/lkml/2004/9/20/104
http://www.thisishull.net/showthread.php?t=44185
http://linux.bkbits.net:8080/linux-2.6/cset@1.1938.326.10?nav=index.html|src/|src/mm|related/mm/prio_tree.c
http://linux.bkbits.net:8080/linux-2.6/gnupatch@418eea50tBOvxQPlZsh__8RNvMAz6Q
Bug #61423.
diff-ve-vestat-misprint
Fixed small misprint in /proc/vz/vestat. User time in jiffies was incorrect.
diff-ms-ip-route-input:
[PATCH] ip_route_input panic fix (CVE-2006-1525)
This fixes kernel.org bug #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 <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff-ms-shmem-writeable
[PATCH] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524)
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 <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff-ms-emt64-rip-on-iret
[PATCH] x86_64: When user could have changed RIP always force IRET (CVE-2006-0744)
Intel EM64T CPUs handle uncanonical return addresses differently from AMD CPUs.
The exception is reported in the SYSRET, not the next instruction. Thgis leads to the kernel exception handler running on the user stack with the wrong GS because the kernel didn't expect exceptions on this instruction.
This version of the patch has the teething problems that plagued an earlier version fixed.
This is CVE-2006-0744
Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial patches.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff-ms-emt64-execve-cleanup
[PATCH] x86_64: Clean up execve
Just call IRET always, no need for any special cases. Needed for the next bug fix.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
diff-vzdq-mnt-20060410
All root dentries are unhashed. We have to check for it in vzquota_check_dtree().
http://forum.openvz.org/index.php?t=tree&goto=2552&#msg_2552
diff-ubc-page-uncharge-20060414
Pages were first put into global list of free pages and ther - uncharged. During this gap page_alloc could charge not uncharged yet page thus causing a BUG().
Moved ub_page_uncharge above freeing and out of local_irq_save to reduce time spent with irqs off.
linux-2.6.8.1-sky2-0.13.patch
adds alternative driver for Marvell Yukon 2 Gigabit Ethernet adapters sources were taken from RHEL4u3 kernel 2.6.9-34EL
Bug #60787
linux-2.6.8.1-libata-1.20.patch
libata driver updated up to 1.20 version
Patch prepared by Vasily (vvs@),
sources were taken from RHEL4U3 kernel 2.6.9-34EL
Obsoleted linux-2.6.8.1-libata-1.11.patch, diff-sis-sata-20060109,
diff-libata-conflicts-20051025.
Bug #52529.
diff-ms-iomap-20060407
torvalds@osdl.org:
"Add skeleton "generic IO mapping" infrastructure.
Jeff wants to use this to clean up SATA and some network drivers."
http://linux.bkbits.net:8080/linux-2.6/gnupatch@4145e7a0KXuy7feBNXoM6_I1fMX9Qg
Bug #52529.
diff-ms-x86_64-iomap-20060407
hunk from mainstream patch, required for libata 1.20/x86_64
[PATCH] amd64 io.h annotations
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
http://linux.bkbits.net:8080/linux-2.6/gnupatch@41785c78CIpmP_kGG3VZwbQjAvOp9Q
Bug #52529.
linux-2.6.9-gpt-partition-noprobe.patch
Patch from RHEL4u3 kernel 2.6.9-34EL:
EFI partitioning scheme was reading the last reported sector of the
block device to look for the alternate GPT header, before it had
confirmed that it should. This causes problems for devices with the
following problems: a) those who misreport their size (typically
off-by-one), and b) those who fail when asked to read a block
outside their range.
This patch moves the test for the Protective Master Boot Record (PMBR) ahead of the tests for the Primary and Alternate GPT headers. If the PMBR is not valid, the disk is assumed to not be a GPT disk. This can be overridden with the 'gpt' kernel command line option. If the Primary GPT header is not valid, the Alternate GPT header is not probed automatically unless the 'gpt' kernel command line option is passed. If the both the PMBR and Primary GPT header are valid, then the Alternate GPT header at the end of the disk is probed.
Also re-enables CONFIG_EFI_PARTITION for all architectures.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com>
Red Hat bug #138563
Bug #61205.
diff-ms-iomem-20051024
diff-ms-nthpage-20051020
added fixes for libata 1.20 update
Bug #52529.
linux-2.6.8.1-drbd-0.7.17.patch
fixed driver version in header file