Open main menu

OpenVZ Virtuozzo Containers Wiki β

Download/kernel/2.6.8/022stab077.1/changes

< Download‎ | kernel‎ | 2.6.8‎ | 022stab077.1
Revision as of 18:25, 22 October 2009 by Kir (talk | contribs) (Protected "Download/kernel/2.6.8/022stab077.1/changes": Robot: Protecting a list of files. [edit=autoconfirmed:move=autoconfirmed])
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

Patch from Dmitry (dim@):

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

Patch from Pavel (xemul@):

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.

OpenVZ Bug #142.

diff-ms-prio-tree-20060420

Patch from mainstream:

[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

Patch from Kirill (dev@):

Fixed small misprint in /proc/vz/vestat. User time in jiffies was incorrect.

diff-ms-ip-route-input:

Patch from mainstream:

[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>

X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=a0b277b4fdcbc24c26af7c5d019e9448a51c79cf

diff-ms-shmem-writeable

Patch from mainstream:

[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>

X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=512dba41bae0ec8de72269167f23b75a4770097d

diff-ms-emt64-rip-on-iret

Patch from mainstream:

[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>

X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commitdiff;h=6b12095a4a0e1f21bbf83f95f13299ca99d758fe

diff-ms-emt64-execve-cleanup

Patch from mainstream:

[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>

X-Git-Url

diff-vzdq-mnt-20060410

Patch from Vasily Tarasov (vtaras@openvz.org):

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

OpenVZ Bug #133.

diff-ubc-page-uncharge-20060414

Patch from Pavel (xemul@):

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.

http://forum.openvz.org/index.php?t=msg&th=465&start=0

linux-2.6.8.1-sky2-0.13.patch

Patch from Vasily (vvs@):

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

Patch from mainstream, required for libata 1.20

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