~thopiekar/linux/+git/linux-stable:linux-2.6.23.y

Last commit made on 2008-02-26
Get this branch:
git clone -b linux-2.6.23.y https://git.launchpad.net/~thopiekar/linux/+git/linux-stable

Branch merges

Branch information

Name:
linux-2.6.23.y
Repository:
lp:~thopiekar/linux/+git/linux-stable

Recent commits

6531868... by Greg Kroah-Hartman <email address hidden> on 2008-02-26

Linux 2.6.23.17

ecf5d43... by Ingo Molnar <email address hidden> on 2008-02-15

x86_64: CPA, fix cache attribute inconsistency bug

no upstream git id as the code has been rewritten.

fix CPA cache attribute bug in v2.6.23. When phys_base is nonzero
(when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
the secondary alias address by -14 MB (depending on the configured
offset).

The default 64-bit kernels of Fedora and Ubuntu are affected:

   $ grep RELOCA /boot/config-2.6.23.9-85.fc8
     CONFIG_RELOCATABLE=y

   $ grep RELOC /boot/config-2.6.22-14-generic
     CONFIG_RELOCATABLE=y

and probably on many other distros as well.

the bug affects all pages in the first 40 MB of physical RAM that
are allocated by some subsystem that does ioremap_nocache() on them:

       if (__pa(address) < KERNEL_TEXT_SIZE) {

Hence we might leave page table entries with inconsistent cache
attributes around (pages mapped at both UnCacheable and Write-Back),
and we can also set the wrong kernel text pages to UnCacheable.

the effects of this bug can be random slowdowns and other misbehavior.
If for example AGP allocates its aperture pages into the first 40 MB
of physical RAM, then the -14 MB bug might mark random kernel texto
pages as uncacheable, slowing down a random portion of the 64-bit
kernel until the AGP driver is unloaded.

Signed-off-by: Ingo Molnar <email address hidden>
Acked-by: Thomas Gleixner <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

8297886... by Jonathan Corbet <email address hidden> on 2008-02-11

Be more robust about bad arguments in get_user_pages()

patch 900cf086fd2fbad07f72f4575449e0d0958f860f in mainline.

So I spent a while pounding my head against my monitor trying to figure
out the vmsplice() vulnerability - how could a failure to check for
*read* access turn into a root exploit? It turns out that it's a buffer
overflow problem which is made easy by the way get_user_pages() is
coded.

In particular, "len" is a signed int, and it is only checked at the
*end* of a do {} while() loop. So, if it is passed in as zero, the loop
will execute once and decrement len to -1. At that point, the loop will
proceed until the next invalid address is found; in the process, it will
likely overflow the pages array passed in to get_user_pages().

I think that, if get_user_pages() has been asked to grab zero pages,
that's what it should do. Thus this patch; it is, among other things,
enough to block the (already fixed) root exploit and any others which
might be lurking in similar code. I also think that the number of pages
should be unsigned, but changing the prototype of this function probably
requires some more careful review.

Signed-off-by: Jonathan Corbet <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

9afecc5... by Benjamin Herrenschmidt on 2008-02-07

Disable G5 NAP mode during SMU commands on U3

patch 592a607bbc053bc6f614a0e619326009f4b3829e in mainline.

It appears that with the U3 northbridge, if the processor is in NAP
mode the whole time while waiting for an SMU command to complete,
then the SMU will fail. It could be related to the weird backward
mechanism the SMU uses to get to system memory via i2c to the
northbridge that doesn't operate properly when the said bridge is
in napping along with the CPU. That is on U3 at least, U4 doesn't
seem to be affected.

This didn't show before NO_HZ as the timer wakeup was enough to make
it work it seems, but that is no longer the case.

This fixes it by disabling NAP mode on those machines while
an SMU command is in flight.

Signed-off-by: Benjamin Herrenschmidt <email address hidden>
Signed-off-by: Paul Mackerras <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

9721a3d... by tglx on 2008-02-19

genirq: do not leave interupts enabled on free_irq

commit 89d694b9dbe769ca1004e01db0ca43964806a611

The default_disable() function was changed in commit:

 76d2160147f43f982dfe881404cfde9fd0a9da21
 genirq: do not mask interrupts by default

It removed the mask function in favour of the default delayed
interrupt disabling. Unfortunately this also broke the shutdown in
free_irq() when the last handler is removed from the interrupt for
those architectures which rely on the default implementations. Now we
can end up with a enabled interrupt line after the last handler was
removed, which can result in spurious interrupts.

Fix this by adding a default_shutdown function, which is only
installed, when the irqchip implementation does provide neither a
shutdown nor a disable function.

Pointed-out-by: Michael Hennerich <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Acked-by: Ingo Molnar <email address hidden>
Tested-by: Michael Hennerich <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

ffff620... by tglx on 2008-02-20

hrtimer: check relative timeouts for overflow

commit: 5a7780e725d1bb4c3094fcc12f1c5c5faea1e988

Various user space callers ask for relative timeouts. While we fixed
that overflow issue in hrtimer_start(), the sites which convert
relative user space values to absolute timeouts themself were uncovered.

Instead of putting overflow checks into each place add a function
which does the sanity checking and convert all affected callers to use
it.

Thanks to Frans Pop, who reported the problem and tested the fixes.

Signed-off-by: Thomas Gleixner <email address hidden>
Acked-by: Ingo Molnar <email address hidden>
Tested-by: Frans Pop <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

2bacfdb... by Jozsef Kadlecsik <email address hidden> on 2008-02-19

NETFILTER: nf_conntrack_tcp: conntrack reopening fix

[NETFILTER]: nf_conntrack_tcp: conntrack reopening fix

[Upstream commits b2155e7f + d0c1fd7a]

TCP connection tracking in netfilter did not handle TCP reopening
properly: active close was taken into account for one side only and
not for any side, which is fixed now. The patch includes more comments
to explain the logic how the different cases are handled.
The bug was discovered by Jeff Chua.

Signed-off-by: Jozsef Kadlecsik <email address hidden>
Signed-off-by: Patrick McHardy <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

9e8927b... by Trond Myklebust on 2008-02-08

NFS: Fix a potential file corruption issue when writing

patch 5d47a35600270e7115061cb1320ee60ae9bcb6b8 in mainline.

If the inode is flagged as having an invalid mapping, then we can't rely on
the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
write optimisation in nfs_updatepage(), since that will cause NFS to write
out areas of the page that are no longer guaranteed to be up to date.

A potential corruption could occur in the following scenario:

client 1 client 2
=============== ===============
    fd=open("f",O_CREAT|O_WRONLY,0644);
    write(fd,"fubar\n",6); // cache last page
    close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"foo\n",4);
close(fd);

    fd=open("f",O_WRONLY|O_APPEND);
    write(fd,"bar\n",4);
    close(fd);
-----
The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
client 2 does not update the cached page after re-opening the file for
write. Instead it keeps it marked as PageUptodate() until someone calls
invaldate_inode_pages2() (typically by calling read()).

Signed-off-by: Trond Myklebust <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

9ec6dbd... by James Bottomley <email address hidden> on 2008-02-02

SCSI: sd: handle bad lba in sense information

patch 366c246de9cec909c5eba4f784c92d1e75b4dc38 in mainline.

Some devices report medium error locations incorrectly. Add guards to
make sure the reported bad lba is actually in the request that caused
it. Additionally remove the large case statment for sector sizes and
replace it with the proper u64 divisions.

Tested-by: Mike Snitzer <email address hidden>
Cc: Stable Tree <email address hidden>
Cc: Tony Battersby <email address hidden>
Signed-off-by: James Bottomley <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

4b30c35... by Greg Kroah-Hartman <email address hidden> on 2008-02-11

Linux 2.6.23.16