kernel, branch linux-2.6.22.y

Linux 2.6.22.19

2008-02-25T23:59:40Z

NETFILTER: nf_conntrack_tcp: conntrack reopening fix

2008-02-25T23:59:23Z

[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 Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman

SCSI: sd: handle bad lba in sense information

2008-02-25T23:59:22Z

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 Cc: Stable Tree Cc: Tony Battersby Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

Be more robust about bad arguments in get_user_pages()

2008-02-25T23:59:21Z

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 Signed-off-by: Linus Torvalds CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman

quicklists: Only consider memory that can be used with GFP_KERNEL

2008-02-25T23:59:21Z

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 Tested-by: Dhaval Giani Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Oliver Pinter

knfsd: query filesystem for NFSv4 getattr of FATTR4_MAXNAME

2008-02-25T23:59:21Z

mainline: a16e92edcd0a2846455a30823e1bac964e743baa Without this we always return 2^32-1 as the the maximum namelength. Signed-off-by: J. Bruce Fields Signed-off-by: Andreas Gruenbacher CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman

NFS: Fix an Oops in encode_lookup()

2008-02-25T23:59:21Z

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 Signed-off-by: Linus Torvalds Acked-by: Neil Brown CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman

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

2008-02-25T23:59:21Z

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 Acked-by: Neil Brown Signed-off-by: Neil Brown CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman

NFS: Fix nfs_reval_fsid()

2008-02-25T23:59:20Z

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 Acked-by: Neil Brown CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman

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

2008-02-25T23:59:20Z

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 for bug report and data collection. Cc: Roland Acked-by: Andreas Gruenbacher Signed-off-by: J. Bruce Fields Reviewed-By: NeilBrown Signed-off-by: Linus Torvalds CC: Oliver Pinter Signed-off-by: Greg Kroah-Hartman