user/sven/linux.git, branch v2.6.22.13

Linux 2.6.22.13

2007-11-16T18:27:09Z

TCP: Make sure write_queue_from does not begin with NULL ptr (CVE-2007-5501)

2007-11-16T18:26:42Z

patch 96a2d41a3e495734b63bff4e5dd0112741b93b38 in mainline. NULL ptr can be returned from tcp_write_queue_head to cached_skb and then assigned to skb if packets_out was zero. Without this, system is vulnerable to a carefully crafted ACKs which obviously is remotely triggerable. Besides, there's very little that needs to be done in sacktag if there weren't any packets outstanding, just skipping the rest doesn't hurt. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

wait_task_stopped: Check p->exit_state instead of TASK_TRACED (CVE-2007-5500)

2007-11-16T18:26:41Z

patch a3474224e6a01924be40a8255636ea5522c1023a in mainline The original meaning of the old test (p->state > TASK_STOPPED) was "not dead", since it was before TASK_TRACED existed and before the state/exit_state split. It was a wrong correction in commit 14bf01bb0599c89fc7f426d20353b76e12555308 to make this test for TASK_TRACED instead. It should have been changed when TASK_TRACED was introducted and again when exit_state was introduced. Signed-off-by: Roland McGrath Cc: Oleg Nesterov Cc: Alexey Dobriyan Cc: Kees Cook Acked-by: Scott James Remnant Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Linux 2.6.22.12

2007-11-05T17:59:33Z

Revert "x86_64: allocate sparsemem memmap above 4G"

2007-11-05T17:56:08Z

patch 6a22c57b8d2a62dea7280a6b2ac807a539ef0716 in mainline. This reverts commit 2e1c49db4c640b35df13889b86b9d62215ade4b6. First off, testing in Fedora has shown it to cause boot failures, bisected down by Martin Ebourne, and reported by Dave Jobes. So the commit will likely be reverted in the 2.6.23 stable kernels. Secondly, in the 2.6.24 model, x86-64 has now grown support for SPARSEMEM_VMEMMAP, which disables the relevant code anyway, so while the bug is not visible any more, it's become invisible due to the code just being irrelevant and no longer enabled on the only architecture that this ever affected. backported to 2.6.22 by Chuck Ebbert Reported-by: Dave Jones Tested-by: Martin Ebourne Cc: Zou Nan hai Cc: Suresh Siddha Cc: Andrew Morton Acked-by: Andy Whitcroft Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

dm snapshot: fix invalidation deadlock

2007-11-05T17:56:07Z

patch fcac03abd325e4f7a4cc8fe05fea2793b1c8eb75 in mainline Process persistent exception store metadata IOs in a separate thread. A snapshot may become invalid while inside generic_make_request(). A synchronous write is then needed to update the metadata while still inside that function. Since the introduction of md-dm-reduce-stack-usage-with-stacked-block-devices.patch this has to be performed by a separate thread to avoid deadlock. Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

x86: fix global_flush_tlb() bug

2007-11-05T17:56:07Z

patch 9a24d04a3c26c223f22493492c5c9085b8773d4a upstream While we were reviewing pageattr_32/64.c for unification, Thomas Gleixner noticed the following serious SMP bug in global_flush_tlb(): down_read(&init_mm.mmap_sem); list_replace_init(&deferred_pages, &l); up_read(&init_mm.mmap_sem); this is SMP-unsafe because list_replace_init() done on two CPUs in parallel can corrupt the list. This bug has been introduced about a year ago in the 64-bit tree: commit ea7322decb974a4a3e804f96a0201e893ff88ce3 Author: Andi Kleen Date: Thu Dec 7 02:14:05 2006 +0100 [PATCH] x86-64: Speed and clean up cache flushing in change_page_attr down_read(&init_mm.mmap_sem); - dpage = xchg(&deferred_pages, NULL); + list_replace_init(&deferred_pages, &l); up_read(&init_mm.mmap_sem); the xchg() based version was SMP-safe, but list_replace_init() is not. So this "cleanup" introduced a nasty bug. why this bug never become prominent is a mystery - it can probably be explained with the (still) relative obscurity of the x86_64 architecture. the safe fix for now is to write-lock init_mm.mmap_sem. Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Cc: Andi Kleen Cc: Andrew Morton Signed-off-by: Greg Kroah-Hartman

param_sysfs_builtin memchr argument fix

2007-11-05T17:56:07Z

patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline. If memchr argument is longer than strlen(kp->name), there will be some weird result. It will casuse duplicate filenames in sysfs for the "nousb". kernel warning messages are as bellow: sysfs: duplicate filename 'usbcore' can not be created WARNING: at fs/sysfs/dir.c:416 sysfs_add_one() [] sysfs_add_one+0xa0/0xe0 [] create_dir+0x48/0xb0 [] sysfs_create_dir+0x29/0x50 [] create_dir+0x1b/0x50 [] kobject_add+0x46/0x150 [] kobject_init+0x3a/0x80 [] kernel_param_sysfs_setup+0x50/0xb0 [] param_sysfs_builtin+0xee/0x130 [] param_sysfs_init+0x23/0x60 [] __next_cpu+0x12/0x20 [] kernel_init+0x0/0xb0 [] kernel_init+0x0/0xb0 [] do_initcalls+0x46/0x1e0 [] create_proc_entry+0x52/0x90 [] register_irq_proc+0x9c/0xc0 [] proc_mkdir_mode+0x34/0x50 [] kernel_init+0x0/0xb0 [] kernel_init+0x62/0xb0 [] kernel_thread_helper+0x7/0x14 ======================= kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory. [] kobject_add+0xf6/0x150 [] kernel_param_sysfs_setup+0x50/0xb0 [] param_sysfs_builtin+0xee/0x130 [] param_sysfs_init+0x23/0x60 [] __next_cpu+0x12/0x20 [] kernel_init+0x0/0xb0 [] kernel_init+0x0/0xb0 [] do_initcalls+0x46/0x1e0 [] create_proc_entry+0x52/0x90 [] register_irq_proc+0x9c/0xc0 [] proc_mkdir_mode+0x34/0x50 [] kernel_init+0x0/0xb0 [] kernel_init+0x62/0xb0 [] kernel_thread_helper+0x7/0x14 ======================= Module 'usbcore' failed to be added to sysfs, error number -17 The system will be unstable now. Signed-off-by: Dave Young Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman

minixfs: limit minixfs printks on corrupted dir i_size (CVE-2006-6058)

2007-11-05T17:56:07Z

patch 44ec6f3f89889a469773b1fd894f8fcc07c29cf in mainline This attempts to address CVE-2006-6058 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6058 first reported at http://projects.info-pull.com/mokb/MOKB-17-11-2006.html Essentially a corrupted minix dir inode reporting a very large i_size will loop for a very long time in minix_readdir, minix_find_entry, etc, because on EIO they just move on to try the next page. This is under the BKL, printk-storming as well. This can lock up the machine for a very long time. Simply ratelimiting the printks gets things back under control. Make the message a bit more informative while we're here. Signed-off-by: Eric Sandeen Cc: Bodo Eggert <7eggert@gmx.de> Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

IB/uverbs: Fix checking of userspace object ownership

2007-11-05T17:56:06Z

Upstream as cbfb50e6e2e9c580848c0f51d37c24cdfb1cb704 Commit 9ead190b ("IB/uverbs: Don't serialize with ib_uverbs_idr_mutex") rewrote how userspace objects are looked up in the uverbs module's idrs, and introduced a severe bug in the process: there is no checking that an operation is being performed by the right process any more. Fix this by adding the missing check of uobj->context in __idr_get_uobj(). Apparently everyone is being very careful to only touch their own objects, because this bug was introduced in June 2006 in 2.6.18, and has gone undetected until now. Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman