commit 00935daeb04cd54a67b66c9e3babc23389251a98 Author: Greg Kroah-Hartman Date: Mon Nov 10 10:50:34 2008 -0800 Linux 2.6.25.20 commit 8419d2eafe89d96cc9e5212dd9effa241ae391bc Author: Patrick McHardy Date: Wed Oct 22 19:41:31 2008 +0200 netfilter: restore lost ifdef guarding defrag exception netfilter: restore lost #ifdef guarding defrag exception Upstream commit 38f7ac3eb: Nir Tzachar reported a warning when sending fragments over loopback with NAT: [ 6658.338121] WARNING: at net/ipv4/netfilter/nf_nat_standalone.c:89 nf_nat_fn+0x33/0x155() The reason is that defragmentation is skipped for already tracked connections. This is wrong in combination with NAT and ip_conntrack actually had some ifdefs to avoid this behaviour when NAT is compiled in. The entire "optimization" may seem a bit silly, for now simply restoring the lost #ifdef is the easiest solution until we can come up with something better. Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit 1f1b1c633ad952ea13eb36a09c6edb4748967d07 Author: Ilpo Järvinen Date: Wed Oct 22 19:41:29 2008 +0200 netfilter: snmp nat leaks memory in case of failure netfilter: snmp nat leaks memory in case of failure Upstream commit 311670f3e: Signed-off-by: Ilpo Jarvinen Signed-off-by: Patrick McHardy commit 78d7a1672fd0191d0acd079015133da2a62f7439 Author: Alexey Dobriyan Date: Wed Oct 22 19:41:28 2008 +0200 netfilter: xt_iprange: fix range inversion match netfilter: xt_iprange: fix range inversion match Upstream commit 6def1eb48: Inverted IPv4 v1 and IPv6 v0 matches don't match anything since 2.6.25-rc1! Signed-off-by: Alexey Dobriyan Acked-by: Jan Engelhardt Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit 8a742297564ff47e7fb938ad1cdfb7caa8db3a37 Author: Julia Jomantaite Date: Mon Oct 27 23:50:57 2008 -0400 ACPI: video: fix brightness allocation Thanks to Arjan for spotting this for .stable: http://www.kerneloops.org/search.php?search=acpi_video_switch_brightness upstream commit 469778c1740fcf3113498b6fdf4559bdec25c58f ACPI: video: fix brightness allocation Fix use of uninitialized device->brightness. Signed-off-by: Julia Jomantaite Signed-off-by: Andi Kleen Acked-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit bf848e9b1c1b67af4db7918814a04502eedf4321 Author: Kumar Gala Date: Tue Oct 21 22:19:00 2008 -0700 math-emu: Fix signalling of underflow and inexact while packing result. [ Upstream commit 930cc144a043ff95e56b6888fa51c618b33f89e7 ] I'm trying to move the powerpc math-emu code to use the include/math-emu bits. In doing so I've been using TestFloat to see how good or bad we are doing. For the most part the current math-emu code that PPC uses has a number of issues that the code in include/math-emu seems to solve (plus bugs we've had for ever that no one every realized). Anyways, I've come across a case that we are flagging underflow and inexact because we think we have a denormalized result from a double precision divide: 000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE soft: 001.0000000000000 ..... syst: 001.0000000000000 ...ux What it looks like is the results out of FP_DIV_D are: D: sign: 0 mantissa: 01000000 00000000 exp: -1023 (0) The problem seems like we aren't normalizing the result and bumping the exp. Now that I'm digging into this a bit I'm thinking my issue has to do with the fix DaveM put in place from back in Aug 2007 (commit 405849610fd96b4f34cd1875c4c033228fea6c0f): [MATH-EMU]: Fix underflow exception reporting. 2) we ended up rounding back up to normal (this is the case where we set the exponent to 1 and set the fraction to zero), this should set inexact too ... Another example, "0x0.0000000000001p-1022 / 16.0", should signal both inexact and underflow. The cpu implementations and ieee1754 literature is very clear about this. This is case #2 above. Here is the distilled glibc test case from Jakub Jelinek which prompted that commit: -------------------- #include #include #include volatile double d = DBL_MIN; volatile double e = 0x0.0000000000001p-1022; volatile double f = 16.0; int main (void) { printf ("%x\n", fetestexcept (FE_UNDERFLOW)); d /= f; printf ("%x\n", fetestexcept (FE_UNDERFLOW)); e /= f; printf ("%x\n", fetestexcept (FE_UNDERFLOW)); return 0; } -------------------- It looks like the case I have we are exact before rounding, but think it looks like the rounding case since it appears as if "overflow is set". 000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE = 001.0000000000000 I think the following adds the check for my case and still works for the issue your commit was trying to resolve. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 33d2a290f61a98eee0e135117bd3f628a5a00a08 Author: Andrea Shepard Date: Sun Oct 19 23:33:03 2008 -0700 sparc64: Fix race in arch/sparc64/kernel/trampoline.S [ Upstream commit e0037df3852b4b60edbe01f70f4968e4a9fdb272 ] Make arch/sparc64/kernel/trampoline.S in 2.6.27.1 lock prom_entry_lock when calling the PROM. This prevents a race condition that I observed causing a hang on startup on a 12-CPU E4500. I am not subscribed to this list, so please CC me on replies. Signed-off-by: Andrea Shepard Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5a150aee377ec6d080ce44d57935e3972136117a Author: Herbert Xu Date: Tue Oct 7 15:50:03 2008 -0700 net: Fix netdev_run_todo dead-lock [ Upstream commit 58ec3b4db9eb5a28e3aec5f407a54e28f7039c19 ] Benjamin Thery tracked down a bug that explains many instances of the error unregister_netdevice: waiting for %s to become free. Usage count = %d It turns out that netdev_run_todo can dead-lock with itself if a second instance of it is run in a thread that will then free a reference to the device waited on by the first instance. The problem is really quite silly. We were trying to create parallelism where none was required. As netdev_run_todo always follows a RTNL section, and that todo tasks can only be added with the RTNL held, by definition you should only need to wait for the very ones that you've added and be done with it. There is no need for a second mutex or spinlock. This is exactly what the following patch does. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 666b1a208ee219ea395c3321cd55d097dd77de95 Author: Ilpo Järvinen Date: Wed Oct 8 14:36:33 2008 -0700 tcpv6: fix option space offsets with md5 [ Upstream commit 53b125779fb0b29e5b316bf3dc7d199e6dcea567 ] More breakage :-), part of timestamps just were previously overwritten. Signed-off-by: Ilpo Järvinen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 507703a31300ca22b2e6d7972eb8d9be7ac22426 Author: Shaohua Li Date: Thu Nov 6 14:18:55 2008 -0500 ACPI: dock: avoid check _STA method commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db upstream. ACPI: dock: avoid check _STA method In some BIOSes, every _STA method call will send a notification again, this cause freeze. And in some BIOSes, it appears _STA should be called after _DCK. This tries to avoid calls _STA, and still keep the device present check. http://bugzilla.kernel.org/show_bug.cgi?id=10431 Signed-off-by: Shaohua Li Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit f46a5d17908de83a415ae0bbc18c53cb596458f3 Author: Takashi Iwai Date: Sun Sep 7 12:51:13 2008 +0200 ALSA: use correct lock in snd_ctl_dev_disconnect() commit d8009882e9f5e1a76986c741f071edd2ad760c97 upstream The lock used in snd_ctl_dev_disconnect() should be card->ctl_files_rwlock for protection of card->ctl_files entries, instead of card->controls_rwsem. Reported-by: Vegard Nossum Signed-off-by: Takashi Iwai Signed-off-by: Jaroslav Kysela Cc: Chris Wedgwood Signed-off-by: Greg Kroah-Hartman commit a41edeec3128be78598eac73a2ea66a77cc198d9 Author: Serge Hallyn Date: Thu Oct 30 11:52:23 2008 -0500 file caps: always start with clear bprm->caps_* commit 3318a386e4ca68c76e0294363d29bdc46fcad670 upstream While Linux doesn't honor setuid on scripts. However, it mistakenly behaves differently for file capabilities. This patch fixes that behavior by making sure that get_file_caps() begins with empty bprm->caps_*. That way when a script is loaded, its bprm->caps_* may be filled when binfmt_misc calls prepare_binprm(), but they will be cleared again when binfmt_elf calls prepare_binprm() next to read the interpreter's file capabilities. Signed-off-by: Serge Hallyn Acked-by: David Howells Acked-by: Andrew G. Morgan Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit aafa27b18c721966bb4320d81781b56176c94cd7 Author: Johannes Berg Date: Sun Nov 2 19:30:21 2008 +0000 libertas: fix buffer overrun commit 48735d8d8bd701b1e0cd3d49c21e5e385ddcb077 upstream If somebody sends an invalid beacon/probe response, that can trash the whole BSS descriptor. The descriptor is, luckily, large enough so that it cannot scribble past the end of it; it's well above 400 bytes long. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 52b5acdd4f41f95472437cdc8886eb195a9e433a Author: David Miller Date: Thu Nov 6 00:37:40 2008 -0800 net: Fix recursive descent in __scm_destroy(). commit f8d570a4745835f2238a33b537218a1bb03fc671 and 3b53fbf4314594fa04544b02b2fc6e607912da18 upstream (because once wasn't good enough...) __scm_destroy() walks the list of file descriptors in the scm_fp_list pointed to by the scm_cookie argument. Those, in turn, can close sockets and invoke __scm_destroy() again. There is nothing which limits how deeply this can occur. The idea for how to fix this is from Linus. Basically, we do all of the fput()s at the top level by collecting all of the scm_fp_list objects hit by an fput(). Inside of the initial __scm_destroy() we keep running the list until it is empty. Signed-off-by: David S. Miller Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e978d59c81b564ae8b213dd32624fc01ce4adacb Author: Benjamin Herrenschmidt Date: Mon Oct 20 16:50:07 2008 +0000 edac cell: fix incorrect edac_mode commit 3b274f44d2ca05f719fe39947b6a5293a2dbd8fd upstream The cell_edac driver is setting the edac_mode field of the csrow's to an incorrect value, causing the sysfs show routine for that field to go out of an array bound and Oopsing the kernel when used. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Doug Thompson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9ba0984488493697cdcb2f235baf6990dd31a310 Author: Eric Sandeen Date: Wed Oct 22 10:11:52 2008 -0500 ext[234]: Avoid printk floods in the face of directory corruption (CVE-2008-3528) This is a trivial backport of the following upstream commits: - bd39597cbd42a784105a04010100e27267481c67 (ext2) - cdbf6dba28e8e6268c8420857696309470009fd9 (ext3) - 9d9f177572d9e4eba0f2e18523b44f90dd51fe74 (ext4) This addresses CVE-2008-3528 ext[234]: Avoid printk floods in the face of directory corruption Note: some people thinks this represents a security bug, since it might make the system go away while it is printing a large number of console messages, especially if a serial console is involved. Hence, it has been assigned CVE-2008-3528, but it requires that the attacker either has physical access to your machine to insert a USB disk with a corrupted filesystem image (at which point why not just hit the power button), or is otherwise able to convince the system administrator to mount an arbitrary filesystem image (at which point why not just include a setuid shell or world-writable hard disk device file or some such). Me, I think they're just being silly. --tytso Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Cc: linux-ext4@vger.kernel.org Cc: Eugene Teo Signed-off-by: Greg Kroah-Hartman commit 9fe2f83d1a17c2428bfbfe7efd4c12571eeb6d22 Author: David Brownell Date: Mon Oct 20 16:50:10 2008 +0000 gpiolib: fix oops in gpio_get_value_cansleep() commit 978ccaa8ea5d8c7bf6b676209f2fc126eae6355b upstream We can get the following oops from gpio_get_value_cansleep() when a GPIO controller doesn't provide a get() callback: Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x00000000 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [00000000] 0x0 LR [c0182fb0] gpio_get_value_cansleep+0x40/0x50 Call Trace: [c7b79e80] [c0183f28] gpio_value_show+0x5c/0x94 [c7b79ea0] [c01a584c] dev_attr_show+0x30/0x7c [c7b79eb0] [c00d6b48] fill_read_buffer+0x68/0xe0 [c7b79ed0] [c00d6c54] sysfs_read_file+0x94/0xbc [c7b79ef0] [c008f24c] vfs_read+0xb4/0x16c [c7b79f10] [c008f580] sys_read+0x4c/0x90 [c7b79f40] [c0013a14] ret_from_syscall+0x0/0x38 It's OK to request the value of *any* GPIO; most GPIOs are bidirectional, so configuring them as outputs just enables an output driver and doesn't disable the input logic. So the problem is that gpio_get_value_cansleep() isn't making the same sanity check that gpio_get_value() does: making sure this GPIO isn't one of the atypical "no input logic" cases. Reported-by: Anton Vorontsov Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman