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

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

Branch merges

Branch information

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

Recent commits

37579d1... by Greg Kroah-Hartman <email address hidden> on 2008-02-25

Linux 2.6.22.19

98d0477... 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>

3b62bc1... 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>

07a854c... by Jonathan Corbet <email address hidden> on 2008-02-17

Be more robust about bad arguments in get_user_pages()

MAINLINE: 900cf086fd2fbad07f72f4575449e0d0958f860f

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>
CC: Oliver Pinter <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

7d495f4... by Christoph Lameter <email address hidden> on 2008-02-17

quicklists: Only consider memory that can be used with GFP_KERNEL

patch 96990a4ae979df9e235d01097d6175759331e88c in mainline.

Quicklists calculates the size of the quicklists based on the number of
free pages. This must be the number of free pages that can be allocated
with GFP_KERNEL. node_page_state() includes the pages in ZONE_HIGHMEM and
ZONE_MOVABLE which may lead the quicklists to become too large causing OOM.

Signed-off-by: Christoph Lameter <email address hidden>
Tested-by: Dhaval Giani <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Oliver Pinter <email address hidden>

ad14c9b... by "J. Bruce Fields" <email address hidden> on 2008-02-07

knfsd: query filesystem for NFSv4 getattr of FATTR4_MAXNAME

mainline: a16e92edcd0a2846455a30823e1bac964e743baa

Without this we always return 2^32-1 as the the maximum namelength.

Signed-off-by: J. Bruce Fields <email address hidden>
Signed-off-by: Andreas Gruenbacher <email address hidden>
CC: Oliver Pinter <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

29301ce... by Trond Myklebust on 2008-02-07

NFS: Fix an Oops in encode_lookup()

mainline: 54af3bb543c071769141387a42deaaab5074da55

It doesn't look as if the NFS file name limit is being initialised correctly
in the struct nfs_server. Make sure that we limit whatever is being set in
nfs_probe_fsinfo() and nfs_init_server().

Also ensure that readdirplus and nfs4_path_walk respect our file name
limits.

Signed-off-by: Trond Myklebust <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
Acked-by: Neil Brown <email address hidden>
CC: Oliver Pinter <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

f3442df... by Trond Myklebust on 2008-02-07

NFSv2/v3: Fix a memory leak when using -onolock

mainline: 5cef338b30c110daf547fb13d99f0c77f2a79fbc

    Neil Brown said:
    > Hi Trond,
    >
    > We found that a machine which made moderately heavy use of
    > 'automount' was leaking some nfs data structures - particularly the
    > 4K allocated by rpc_alloc_iostats.
    > It turns out that this only happens with filesystems with -onolock
    > set.

    > The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't
    > set server->destroy, so when the filesystem is unmounted, the
    > ->client_acl is not shutdown, and so several resources are still
    > held. Multiple mount/umount cycles will slowly eat away memory
    > several pages at a time.

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

Acked-by: Neil Brown <email address hidden>
Signed-off-by: Neil Brown <email address hidden>
CC: Oliver Pinter <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

89f2dc0... by Trond Myklebust on 2008-02-07

NFS: Fix nfs_reval_fsid()

mainline: a0356862bcbeb20acf64bc1a82d28a4c5bb957a7

We don't need to revalidate the fsid on the root directory. It suffices to
revalidate it on the current directory.

Signed-off-by: Trond Myklebust <email address hidden>
Acked-by: Neil Brown <email address hidden>
CC: Oliver Pinter <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>

e48a28b... by "J. Bruce Fields" <email address hidden> on 2008-02-07

knfsd: fix spurious EINVAL errors on first access of new filesystem

mainline: ac8587dcb58e40dd336d99d60f852041e06cc3dd

The v2/v3 acl code in nfsd is translating any return from fh_verify() to
nfserr_inval. This is particularly unfortunate in the case of an
nfserr_dropit return, which is an internal error meant to indicate to
callers that this request has been deferred and should just be dropped
pending the results of an upcall to mountd.

Thanks to Roland <email address hidden> for bug report and data collection.

Cc: Roland <email address hidden>
Acked-by: Andreas Gruenbacher <email address hidden>
Signed-off-by: J. Bruce Fields <email address hidden>
Reviewed-By: NeilBrown <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
CC: Oliver Pinter <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>