commit 7d41d745d2e4e7e0dca334f9f1991db290ab6d4b Author: Greg Kroah-Hartman Date: Mon Sep 8 03:20:51 2008 -0700 Linux 2.6.25.17 commit 01b140eb2108f7c30e01659a573a971bc8ca3dea Author: Thomas Graf Date: Wed Sep 3 01:00:02 2008 -0700 sch_prio: Fix nla_parse_nested_compat() regression [ No upstream commit, this is fixing code no longer in 2.6.27 ] nla_parse_nested_compat() was used to parse two different message formats in the netem and prio qdisc, when it was "fixed" to work with netem, it broke the multi queue support in the prio qdisc. Since the prio qdisc code in question is already removed in the development tree, this patch only fixes the regression in the stable tree. Based on original patch from Alexander H Duyck Signed-off-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6d204e4fe042aafb1e443b08de56b4fa5cf012ca Author: Vlad Yasevich Date: Wed Sep 3 01:02:37 2008 -0700 sctp: fix random memory dereference with SCTP_HMAC_IDENT option. [ Upstream commit d97240552cd98c4b07322f30f66fd9c3ba4171de ] The number of identifiers needs to be checked against the option length. Also, the identifier index provided needs to be verified to make sure that it doesn't exceed the bounds of the array. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 113de4111795af1245a84368c233f25699999908 Author: Vlad Yasevich Date: Wed Sep 3 01:02:19 2008 -0700 sctp: correct bounds check in sctp_setsockopt_auth_key [ Upstream commit 328fc47ea0bcc27d9afa69c3ad6e52431cadd76c ] The bonds check to prevent buffer overlflow was not exactly right. It still allowed overflow of up to 8 bytes which is sizeof(struct sctp_authkey). Since optlen is already checked against the size of that struct, we are guaranteed not to cause interger overflow either. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1c6f8e1945a2b8317e5dad8fb5cfc882bd35b2b8 Author: Vlad Yasevich Date: Wed Aug 27 22:41:52 2008 -0700 sctp: add verification checks to SCTP_AUTH_KEY option [ Upstream commit 30c2235cbc477d4629983d440cdc4f496fec9246 ] The structure used for SCTP_AUTH_KEY option contains a length that needs to be verfied to prevent buffer overflow conditions. Spoted by Eugene Teo . Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a1d348ddecaee92e74c27ccd69c325f4ce01d95f Author: Vlad Yasevich Date: Wed Aug 27 22:41:00 2008 -0700 sctp: fix potential panics in the SCTP-AUTH API. [ Upstream commit 5e739d1752aca4e8f3e794d431503bfca3162df4 ] All of the SCTP-AUTH socket options could cause a panic if the extension is disabled and the API is envoked. Additionally, there were some additional assumptions that certain pointers would always be valid which may not always be the case. This patch hardens the API and address all of the crash scenarios. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit de9148e41ee5015feb2bfdc86ae65d8cea4c02d6 Author: Jeff Layton Date: Tue Sep 2 19:25:05 2008 +0000 cifs: fix O_APPEND on directio mounts commit 838726c4756813576078203eb7e1e219db0da870 upstream The direct I/O write codepath for CIFS is done through cifs_user_write(). That function does not currently call generic_write_checks() so the file position isn't being properly set when the file is opened with O_APPEND. It's also not doing the other "normal" checks that should be done for a write call. The problem is currently that when you open a file with O_APPEND on a mount with the directio mount option, the file position is set to the beginning of the file. This makes any subsequent writes clobber the data in the file starting at the beginning. This seems to fix the problem in cursory testing. It is, however important to note that NFS disallows the combination of (O_DIRECT|O_APPEND). If my understanding is correct, the concern is races with multiple clients appending to a file clobbering each others' data. Since the write model for CIFS and NFS is pretty similar in this regard, CIFS is probably subject to the same sort of races. What's unclear to me is why this is a particular problem with O_DIRECT and not with buffered writes... Regardless, disallowing O_APPEND on an entire mount is probably not reasonable, so we'll probably just have to deal with it and reevaluate this flag combination when we get proper support for O_DIRECT. In the meantime this patch at least fixes the existing problem. Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a9e93fe0ed25ec98c3f07fe0f2435f9f9a2cb962 Author: Al Viro Date: Wed Aug 20 22:50:04 2008 +0000 cramfs: fix named-pipe handling commit 82d63fc9e30687c055b97928942b8893ea65b0bb upstream After commit a97c9bf33f4612e2aed6f000f6b1d268b6814f3c (fix cramfs making duplicate entries in inode cache) in kernel 2.6.14, named-pipe on cramfs does not work properly. It seems the commit make all named-pipe on cramfs share their inode (and named-pipe buffer). Make ..._test() refuse to merge inodes with ->i_ino == 1, take inode setup back to get_cramfs_inode() and make ->drop_inode() evict ones with ->i_ino == 1 immediately. Reported-by: Atsushi Nemoto Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6d37b9e156a282eb959d8457c2baca13083b36ea Author: Herbert Xu Date: Sat Aug 23 09:36:17 2008 +1000 crypto: authenc - Avoid using clobbered request pointer crypto: authenc - Avoid using clobbered request pointer [ Upstream commit: a697690bece75d4ba424c1318eb25c37d41d5829 ] Authenc works in two stages for encryption, it first encrypts and then computes an ICV. The context memory of the request is used by both operations. The problem is that when an asynchronous encryption completes, we will compute the ICV and then reread the context memory of the encryption to get the original request. It just happens that we have a buffer of 16 bytes in front of the request pointer, so ICVs of 16 bytes (such as SHA1) do not trigger the bug. However, any attempt to uses a larger ICV instantly kills the machine when the first asynchronous encryption is completed. This patch fixes this by saving the request pointer before we start the ICV computation. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit bb470a3cd32f9f994113784ea685d40d1cfbbdd8 Author: Ian Campbell Date: Wed Aug 20 22:50:11 2008 +0000 fbdefio: add set_page_dirty handler to deferred IO FB commit d847471d063663b9f36927d265c66a270c0cfaab upstream Fixes kernel BUG at lib/radix-tree.c:473. Previously the handler was incidentally provided by tmpfs but this was removed with: commit 14fcc23fdc78e9d32372553ccf21758a9bd56fa1 Author: Hugh Dickins Date: Mon Jul 28 15:46:19 2008 -0700 tmpfs: fix kernel BUG in shmem_delete_inode relying on this behaviour was incorrect in any case and the BUG also appeared when the device node was on an ext3 filesystem. v2: override a_ops at open() time rather than mmap() time to minimise races per AKPM's concerns. Signed-off-by: Ian Campbell Cc: Jaya Kumar Cc: Nick Piggin Cc: Peter Zijlstra Cc: Hugh Dickins Cc: Johannes Weiner Cc: Jeremy Fitzhardinge Cc: Kel Modderman Cc: Markus Armbruster Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b5b97cfba4d42bd231fe0d0566d849c6ac20547d Author: Ayaz Abdulla Date: Thu Aug 28 19:40:03 2008 +0000 forcedeth: fix checksum flag commit edcfe5f7e307846e578fb88d69fa27051fded0ab upstream Fix the checksum feature advertised in device flags. The hardware support TCP/UDP over IPv4 and TCP/UDP over IPv6 (without IPv6 extension headers). However, the kernel feature flags do not distinguish IPv6 with/without extension headers. Therefore, the driver needs to use NETIF_F_IP_CSUM instead of NETIF_F_HW_CSUM since the latter includes all IPv6 packets. A future patch can be created to check for extension headers and perform software checksum calculation. Signed-off-by: Ayaz Abdulla Cc: Jeff Garzik Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 30c90fbfe9498f7410131821510a95437016e77b Author: Adam Litke Date: Wed Sep 3 02:35:08 2008 +0000 mm: make setup_zone_migrate_reserve() aware of overlapping nodes commit 344c790e3821dac37eb742ddd0b611a300f78b9a upstream I have gotten to the root cause of the hugetlb badness I reported back on August 15th. My system has the following memory topology (note the overlapping node): Node 0 Memory: 0x8000000-0x44000000 Node 1 Memory: 0x0-0x8000000 0x44000000-0x80000000 setup_zone_migrate_reserve() scans the address range 0x0-0x8000000 looking for a pageblock to move onto the MIGRATE_RESERVE list. Finding no candidates, it happily continues the scan into 0x8000000-0x44000000. When a pageblock is found, the pages are moved to the MIGRATE_RESERVE list on the wrong zone. Oops. setup_zone_migrate_reserve() should skip pageblocks in overlapping nodes. Signed-off-by: Adam Litke Acked-by: Mel Gorman Cc: Dave Hansen Cc: Nishanth Aravamudan Cc: Andy Whitcroft Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9a5cb39966e999307602b7747cf9c01e0e389eb2 Author: J. Bruce Fields Date: Mon Sep 1 14:51:02 2008 -0400 nfsd: fix buffer overrun decoding NFSv4 acl commit 91b80969ba466ba4b915a4a1d03add8c297add3f upstream The array we kmalloc() here is not large enough. Thanks to Johann Dahm and David Richter for bug report and testing. Signed-off-by: J. Bruce Fields Cc: David Richter Tested-by: Johann Dahm Signed-off-by: Greg Kroah-Hartman commit a3ec4ed4b27926b224a5acc2325d70a50f75c48d Author: Francois Romieu Date: Thu Aug 28 22:55:33 2008 +0200 r8169: balance pci_map / pci_unmap pair commit a866bbf6aacf95f849810079442a20be118ce905 upstream The leak hurts with swiotlb and jumbo frames. Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468. Heavily hinted by Ilpo Järvinen . Signed-off-by: Francois Romieu Tested-by: Alistair John Strachan Tested-by: Timothy J Fontaine Cc: Edward Hsu Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit fde5378952ed3550b5e0eb2310be6687baeed143 Author: Cyrill Gorcunov Date: Mon Sep 1 14:51:01 2008 -0400 sunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports commit 27df6f25ff218072e0e879a96beeb398a79cdbc8 upstream Vegard Nossum reported ---------------------- > I noticed that something weird is going on with /proc/sys/sunrpc/transports. > This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When > I "cat" this file, I get the expected output: > $ cat /proc/sys/sunrpc/transports > tcp 1048576 > udp 32768 > But I think that it does not check the length of the buffer supplied by > userspace to read(). With my original program, I found that the stack was > being overwritten by the characters above, even when the length given to > read() was just 1. David Wagner added (among other things) that copy_to_user could be probably used here. Ingo Oeser suggested to use simple_read_from_buffer() here. The conclusion is that proc_do_xprt doesn't check for userside buffer size indeed so fix this by using Ingo's suggestion. Reported-by: Vegard Nossum Signed-off-by: Cyrill Gorcunov CC: Ingo Oeser Cc: Neil Brown Cc: Chuck Lever Cc: Greg Banks Cc: Tom Tucker Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 76bc2fb2bbf15d4e20504e623237b086c5d1ff2c Author: Alexey Dobriyan Date: Fri Aug 22 17:40:10 2008 +0000 USB: cdc-acm: don't unlock acm->mutex on error path commit 74573ee7096a4ffc2f098108d21c85801b9c7434 upstream On Wed, Jul 23, 2008 at 03:52:36PM +0300, Andrei Popa wrote: > I installed gnokii-0.6.22-r2 and gave the command "gnokii --identify" > and the kernel oopsed: > > BUG: unable to handle kernel NULL pointer dereference at 00000458 > IP: [] mutex_unlock+0x0/0xb > [] acm_tty_open+0x4c/0x214 Signed-off-by: Alexey Dobriyan Tested-by: Andrei Popa Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8e023f85b670c9f6008df675b6b213025b3387b3 Author: Yinghai Lu Date: Fri Aug 22 17:40:05 2008 +0000 x86: work around MTRR mask setting commit 38cc1c3df77c1bb739a4766788eb9fa49f16ffdf upstream Joshua Hoblitt reported that only 3 GB of his 16 GB of RAM is usable. Booting with mtrr_show showed us the BIOS-initialized MTRR settings - which are all wrong. So the root cause is that the BIOS has not set the mask correctly: > [ 0.429971] MSR00000200: 00000000d0000000 > [ 0.433305] MSR00000201: 0000000ff0000800 > should be ==> [ 0.433305] MSR00000201: 0000003ff0000800 > > [ 0.436638] MSR00000202: 00000000e0000000 > [ 0.439971] MSR00000203: 0000000fe0000800 > should be ==> [ 0.439971] MSR00000203: 0000003fe0000800 > > [ 0.443304] MSR00000204: 0000000000000006 > [ 0.446637] MSR00000205: 0000000c00000800 > should be ==> [ 0.446637] MSR00000205: 0000003c00000800 > > [ 0.449970] MSR00000206: 0000000400000006 > [ 0.453303] MSR00000207: 0000000fe0000800 > should be ==> [ 0.453303] MSR00000207: 0000003fe0000800 > > [ 0.456636] MSR00000208: 0000000420000006 > [ 0.459970] MSR00000209: 0000000ff0000800 > should be ==> [ 0.459970] MSR00000209: 0000003ff0000800 So detect this borkage and add the prefix 111. Signed-off-by: Yinghai Lu Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman