commit f8b025c5aed3e470becedf707bc73fad38efab47 Author: Greg Kroah-Hartman Date: Sun Jul 19 20:45:22 2009 -0700 Linux 2.6.27.27 commit 7d317ec29c587f76bbfa375ef3b832204f5bffe5 Author: Linus Torvalds Date: Sun Jul 12 11:25:04 2009 -0700 Don't use '-fwrapv' compiler option: it's buggy in gcc-4.1.x commit a137802ee839ace40079bebde24cfb416f73208a upstream. This causes kernel images that don't run init to completion with certain broken gcc versions. This fixes kernel bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=13012 I suspect the gcc problem is this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230 Fix the problem by using the -fno-strict-overflow flag instead, which not only does not exist in the known-to-be-broken versions of gcc (it was introduced later than fwrapv), but seems to be much less disturbing to gcc too: the difference in the generated code by -fno-strict-overflow are smaller (compared to using neither flag) than when using -fwrapv. Reported-by: Barry K. Nathan Pushed-by: Frans Pop Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0d3d2711b2dd74f39a21ed20b88d733e9509100a Author: Tomasz Lemiech Date: Fri Mar 13 15:43:38 2009 -0700 tulip: Fix for MTU problems with 802.1q tagged frames commit 1f8ae0a21d83f43006d7f6d2862e921dbf2eeddd upstream. The original patch was submitted last year but wasn't discussed or applied because of missing maintainer's CCs. I only fixed some formatting errors, but as I saw tulip is very badly formatted and needs further work. Original description: This patch fixes MTU problem, which occurs when using 802.1q VLANs. We should allow receiving frames of up to 1518 bytes in length, instead of 1514. Based on patch written by Ben McKeegan for 2.4.x kernels. It is archived at http://www.candelatech.com/~greear/vlan/howto.html#tulip I've adjusted a few things to make it apply on 2.6.x kernels. Tested on D-Link DFE-570TX quad-fastethernet card. Signed-off-by: Tomasz Lemiech Signed-off-by: Ivan Vecera Signed-off-by: Ben McKeegan Acked-by: Grant Grundler Cc: Christoph Biedl Signed-off-by: David S. Miller commit 01a6403211958921247f4e65b16376e6ec706a0d Author: Zhang Rui Date: Tue Jun 30 11:41:31 2009 -0700 kernel/resource.c: fix sign extension in reserve_setup() commit 8bc1ad7dd301b7ca7454013519fa92e8c53655ff upstream. When the 32-bit signed quantities get assigned to the u64 resource_size_t, they are incorrectly sign-extended. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13253 Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9905 Signed-off-by: Zhang Rui Reported-by: Leann Ogasawara Cc: Pierre Ossman Reported-by: Tested-by: Cc: Jesse Barnes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4af3aa317b819743c34e1f1b0bb989e132eaad46 Author: Jiri Slaby Date: Tue Jun 30 11:41:44 2009 -0700 floppy: fix lock imbalance commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream. A crappy macro prevents us unlocking on a fail path. Expand the macro and unlock appropriatelly. Signed-off-by: Jiri Slaby Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a6dcca1cfed58986d9d0f5c0092855de946b4a91 Author: David Woodhouse Date: Wed Jul 1 18:49:06 2009 +0100 Fix iommu address space allocation commit a15a519ed6e5e644f5a33c213c00b0c1d3cfe683 upstream. This fixes kernel.org bug #13584. The IOVA code attempted to optimise the insertion of new ranges into the rbtree, with the unfortunate result that some ranges just didn't get inserted into the tree at all. Then those ranges would be handed out more than once, and things kind of go downhill from there. Introduced after 2.6.25 by ddf02886cbe665d67ca750750196ea5bf524b10b ("PCI: iova RB tree setup tweak"). Signed-off-by: David Woodhouse Cc: mark gross Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d6055cd3a734696779d238f9e54174954f22c4c9 Author: Christoph Lameter Date: Wed Jun 3 16:04:31 2009 -0400 security: use mmap_min_addr indepedently of security models commit e0a94c2a63f2644826069044649669b5e7ca75d3 upstream. This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY. It also sets a default mmap_min_addr of 4096. mmapping of addresses below 4096 will only be possible for processes with CAP_SYS_RAWIO. Signed-off-by: Christoph Lameter Acked-by: Eric Paris Looks-ok-by: Linus Torvalds Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 92e7e4cf8ce653e532aa3cb9857df8316a6b2731 Author: Julien Tinnes Date: Fri Jun 26 20:27:40 2009 +0200 personality: fix PER_CLEAR_ON_SETID (CVE-2009-1895) commit f9fabcb58a6d26d6efde842d1703ac7cfa9427b6 upstream. We have found that the current PER_CLEAR_ON_SETID mask on Linux doesn't include neither ADDR_COMPAT_LAYOUT, nor MMAP_PAGE_ZERO. The current mask is READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE. We believe it is important to add MMAP_PAGE_ZERO, because by using this personality it is possible to have the first page mapped inside a process running as setuid root. This could be used in those scenarios: - Exploiting a NULL pointer dereference issue in a setuid root binary - Bypassing the mmap_min_addr restrictions of the Linux kernel: by running a setuid binary that would drop privileges before giving us control back (for instance by loading a user-supplied library), we could get the first page mapped in a process we control. By further using mremap and mprotect on this mapping, we can then completely bypass the mmap_min_addr restrictions. Less importantly, we believe ADDR_COMPAT_LAYOUT should also be added since on x86 32bits it will in practice disable most of the address space layout randomization (only the stack will remain randomized). Signed-off-by: Julien Tinnes Signed-off-by: Tavis Ormandy Acked-by: Christoph Hellwig Acked-by: Kees Cook Acked-by: Eugene Teo [ Shortened lines and fixed whitespace as per Christophs' suggestion ] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0e7b110967831c56510ca05ebc521c634818cd25 Author: Eugene Teo Date: Wed Jul 15 14:59:10 2009 +0800 Add '-fno-delete-null-pointer-checks' to gcc CFLAGS commit a3ca86aea507904148870946d599e07a340b39bf upstream. Turning on this flag could prevent the compiler from optimising away some "useless" checks for null pointers. Such bugs can sometimes become exploitable at compile time because of the -O2 optimisation. See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html An example that clearly shows this 'problem' is commit 6bf67672. static void __devexit agnx_pci_remove(struct pci_dev *pdev) { struct ieee80211_hw *dev = pci_get_drvdata(pdev); - struct agnx_priv *priv = dev->priv; + struct agnx_priv *priv; AGNX_TRACE; if (!dev) return; + priv = dev->priv; By reverting this patch, and compile it with and without -fno-delete-null-pointer-checks flag, we can see that the check for dev is compiled away. call printk # - testq %r12, %r12 # dev - je .L94 #, movq %r12, %rdi # dev, Clearly the 'fix' is to stop using dev before it is tested, but building with -fno-delete-null-pointer-checks flag at least makes it harder to abuse. Signed-off-by: Eugene Teo Acked-by: Eric Paris Acked-by: Wang Cong Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c58a659e521fbb8f590a0b042041555855bf976c Author: Greg Kroah-Hartman Date: Sun Jul 19 20:43:27 2009 -0700 Revert "dm: sysfs skip output when device is being destroyed" This reverts commit 9fad9f263a7065be94bf77519346d0d854ff3b92. It is really commit 4d89b7b4e4726893453d0fb4ddbb5b3e16353994 that is being reverted here, it's a patch that should not have been applied to the .27 tree. Signed-off-by: Greg Kroah-Hartman