* [patch 1/8] Add -fno-delete-null-pointer-checks to gcc CFLAGS
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
@ 2009-07-17 20:37 ` Greg KH
2009-07-17 20:37 ` [patch 2/8] personality: fix PER_CLEAR_ON_SETID (CVE-2009-1895) Greg KH
` (7 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Eugene Teo, Eric Paris,
Wang Cong
[-- Attachment #1: add-fno-delete-null-pointer-checks-to-gcc-cflags.patch --]
[-- Type: text/plain, Size: 1962 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Eugene Teo <eteo@redhat.com>
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 <eugeneteo@kernel.sg>
Acked-by: Eric Paris <eparis@redhat.com>
Acked-by: Wang Cong <amwang@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/Makefile
+++ b/Makefile
@@ -340,7 +340,8 @@ KBUILD_CPPFLAGS := -D__KERNEL__ $(LINUXI
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
- -Werror-implicit-function-declaration
+ -Werror-implicit-function-declaration \
+ -fno-delete-null-pointer-checks
KBUILD_AFLAGS := -D__ASSEMBLY__
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 2/8] personality: fix PER_CLEAR_ON_SETID (CVE-2009-1895)
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
2009-07-17 20:37 ` [patch 1/8] Add -fno-delete-null-pointer-checks to gcc CFLAGS Greg KH
@ 2009-07-17 20:37 ` Greg KH
2009-07-17 20:37 ` [patch 3/8] security: use mmap_min_addr indepedently of security models Greg KH
` (6 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Julien Tinnes, Tavis Ormandy,
Christoph Hellwig, Kees Cook, Eugene Teo
[-- Attachment #1: personality-fix-per_clear_on_setid.patch --]
[-- Type: text/plain, Size: 2194 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Julien Tinnes <jt@cr0.org>
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 <jt@cr0.org>
Signed-off-by: Tavis Ormandy <taviso@sdf.lonestar.org>
Acked-by: Christoph Hellwig <hch@infradead.org>
Acked-by: Kees Cook <kees@ubuntu.com>
Acked-by: Eugene Teo <eugene@redhat.com>
[ Shortened lines and fixed whitespace as per Christophs' suggestion ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/personality.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/include/linux/personality.h
+++ b/include/linux/personality.h
@@ -40,7 +40,10 @@ enum {
* Security-relevant compatibility flags that must be
* cleared upon setuid or setgid exec:
*/
-#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE)
+#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC | \
+ ADDR_NO_RANDOMIZE | \
+ ADDR_COMPAT_LAYOUT | \
+ MMAP_PAGE_ZERO)
/*
* Personality types.
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 3/8] security: use mmap_min_addr indepedently of security models
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
2009-07-17 20:37 ` [patch 1/8] Add -fno-delete-null-pointer-checks to gcc CFLAGS Greg KH
2009-07-17 20:37 ` [patch 2/8] personality: fix PER_CLEAR_ON_SETID (CVE-2009-1895) Greg KH
@ 2009-07-17 20:37 ` Greg KH
2009-07-17 20:37 ` [patch 4/8] Fix iommu address space allocation Greg KH
` (5 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Christoph Lameter,
Eric Paris, James Morris
[-- Attachment #1: security-use-mmap_min_addr-indepedently-of-security-models.patch --]
[-- Type: text/plain, Size: 5129 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Christoph Lameter <cl@linux-foundation.org>
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 <cl@linux-foundation.org>
Acked-by: Eric Paris <eparis@redhat.com>
Looks-ok-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/mm.h | 2 --
include/linux/security.h | 2 ++
kernel/sysctl.c | 2 --
mm/Kconfig | 18 ++++++++++++++++++
mm/mmap.c | 3 +++
security/Kconfig | 22 +---------------------
security/security.c | 3 ---
7 files changed, 24 insertions(+), 28 deletions(-)
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -572,12 +572,10 @@ static inline void set_page_links(struct
*/
static inline unsigned long round_hint_to_min(unsigned long hint)
{
-#ifdef CONFIG_SECURITY
hint &= PAGE_MASK;
if (((void *)hint != NULL) &&
(hint < mmap_min_addr))
return PAGE_ALIGN(mmap_min_addr);
-#endif
return hint;
}
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2134,6 +2134,8 @@ static inline int security_file_mmap(str
unsigned long addr,
unsigned long addr_only)
{
+ if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
+ return -EACCES;
return 0;
}
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1132,7 +1132,6 @@ static struct ctl_table vm_table[] = {
.strategy = &sysctl_jiffies,
},
#endif
-#ifdef CONFIG_SECURITY
{
.ctl_name = CTL_UNNUMBERED,
.procname = "mmap_min_addr",
@@ -1141,7 +1140,6 @@ static struct ctl_table vm_table[] = {
.mode = 0644,
.proc_handler = &proc_doulongvec_minmax,
},
-#endif
#ifdef CONFIG_NUMA
{
.ctl_name = CTL_UNNUMBERED,
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -208,3 +208,21 @@ config VIRT_TO_BUS
config MMU_NOTIFIER
bool
+
+config DEFAULT_MMAP_MIN_ADDR
+ int "Low address space to protect from user allocation"
+ default 4096
+ help
+ This is the portion of low virtual memory which should be protected
+ from userspace allocation. Keeping a user from writing to low pages
+ can help reduce the impact of kernel NULL pointer bugs.
+
+ For most ia64, ppc64 and x86 users with lots of address space
+ a value of 65536 is reasonable and should cause no problems.
+ On arm and other archs it should not be higher than 32768.
+ Programs which use vm86 functionality would either need additional
+ permissions from either the LSM or the capabilities module or have
+ this protection disabled.
+
+ This value can be changed after boot using the
+ /proc/sys/vm/mmap_min_addr tunable.
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -86,6 +86,9 @@ int sysctl_overcommit_ratio = 50; /* def
int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
atomic_long_t vm_committed_space = ATOMIC_LONG_INIT(0);
+/* amount of vm to protect from userspace access */
+unsigned long mmap_min_addr = CONFIG_DEFAULT_MMAP_MIN_ADDR;
+
/*
* Check that a process has enough memory to allocate a new virtual
* mapping. 0 means there is enough memory for the allocation to
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -92,28 +92,8 @@ config SECURITY_ROOTPLUG
See <http://www.linuxjournal.com/article.php?sid=6279> for
more information about this module.
-
- If you are unsure how to answer this question, answer N.
-
-config SECURITY_DEFAULT_MMAP_MIN_ADDR
- int "Low address space to protect from user allocation"
- depends on SECURITY
- default 0
- help
- This is the portion of low virtual memory which should be protected
- from userspace allocation. Keeping a user from writing to low pages
- can help reduce the impact of kernel NULL pointer bugs.
-
- For most ia64, ppc64 and x86 users with lots of address space
- a value of 65536 is reasonable and should cause no problems.
- On arm and other archs it should not be higher than 32768.
- Programs which use vm86 functionality would either need additional
- permissions from either the LSM or the capabilities module or have
- this protection disabled.
-
- This value can be changed after boot using the
- /proc/sys/vm/mmap_min_addr tunable.
+ If you are unsure how to answer this question, answer N.
source security/selinux/Kconfig
source security/smack/Kconfig
--- a/security/security.c
+++ b/security/security.c
@@ -26,9 +26,6 @@ extern void security_fixup_ops(struct se
struct security_operations *security_ops; /* Initialized to NULL */
-/* amount of vm to protect from userspace access */
-unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;
-
static inline int verify(struct security_operations *ops)
{
/* verify the security_operations structure exists */
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 4/8] Fix iommu address space allocation
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
` (2 preceding siblings ...)
2009-07-17 20:37 ` [patch 3/8] security: use mmap_min_addr indepedently of security models Greg KH
@ 2009-07-17 20:37 ` Greg KH
2009-07-17 20:37 ` [patch 5/8] floppy: fix lock imbalance Greg KH
` (4 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, David Woodhouse, mark gross
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: fix-iommu-address-space-allocation.patch --]
[-- Type: text/plain, Size: 2527 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Woodhouse <dwmw2@infradead.org>
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 <David.Woodhouse@intel.com>
Cc: mark gross <mgross@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/pci/iova.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
--- a/drivers/pci/iova.c
+++ b/drivers/pci/iova.c
@@ -1,9 +1,19 @@
/*
- * Copyright (c) 2006, Intel Corporation.
+ * Copyright © 2006-2009, Intel Corporation.
*
- * This file is released under the GPLv2.
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
*
- * Copyright (C) 2006-2008 Intel Corporation
* Author: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
*/
@@ -123,7 +133,15 @@ move_left:
/* Insert the new_iova into domain rbtree by holding writer lock */
/* Add new node and rebalance tree. */
{
- struct rb_node **entry = &((prev)), *parent = NULL;
+ struct rb_node **entry, *parent = NULL;
+
+ /* If we have 'prev', it's a valid place to start the
+ insertion. Otherwise, start from the root. */
+ if (prev)
+ entry = &prev;
+ else
+ entry = &iovad->rbroot.rb_node;
+
/* Figure out where to put new node */
while (*entry) {
struct iova *this = container_of(*entry,
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 5/8] floppy: fix lock imbalance
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
` (3 preceding siblings ...)
2009-07-17 20:37 ` [patch 4/8] Fix iommu address space allocation Greg KH
@ 2009-07-17 20:37 ` Greg KH
2009-07-17 20:37 ` [patch 6/8] kernel/resource.c: fix sign extension in reserve_setup() Greg KH
` (3 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Jiri Slaby, Jens Axboe
[-- Attachment #1: floppy-fix-lock-imbalance.patch --]
[-- Type: text/plain, Size: 1079 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jiri Slaby <jirislaby@gmail.com>
commit 8516a500029890a72622d245f8ed32c4e30969b7 upstream.
A crappy macro prevents us unlocking on a fail path.
Expand the macro and unlock appropriatelly.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/block/floppy.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3320,7 +3320,10 @@ static inline int set_geometry(unsigned
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
mutex_lock(&open_lock);
- LOCK_FDC(drive, 1);
+ if (lock_fdc(drive, 1)) {
+ mutex_unlock(&open_lock);
+ return -EINTR;
+ }
floppy_type[type] = *g;
floppy_type[type].name = "user format";
for (cnt = type << 2; cnt < (type << 2) + 4; cnt++)
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 6/8] kernel/resource.c: fix sign extension in reserve_setup()
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
` (4 preceding siblings ...)
2009-07-17 20:37 ` [patch 5/8] floppy: fix lock imbalance Greg KH
@ 2009-07-17 20:37 ` Greg KH
2009-07-17 20:37 ` [patch 7/8] tulip: Fix for MTU problems with 802.1q tagged frames Greg KH
` (2 subsequent siblings)
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Zhang Rui, Pierre Ossman,
Jesse Barnes
[-- Attachment #1: kernel-resource.c-fix-sign-extension-in-reserve_setup.patch --]
[-- Type: text/plain, Size: 1228 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Zhang Rui <rui.zhang@intel.com>
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 <rui.zhang@intel.com>
Reported-by: Leann Ogasawara <leann@ubuntu.com>
Cc: Pierre Ossman <drzeus@drzeus.cx>
Reported-by: <pablomme@googlemail.com>
Tested-by: <pablomme@googlemail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -741,7 +741,7 @@ static int __init reserve_setup(char *st
static struct resource reserve[MAXRESERVE];
for (;;) {
- int io_start, io_num;
+ unsigned int io_start, io_num;
int x = reserved;
if (get_option (&str, &io_start) != 2)
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 7/8] tulip: Fix for MTU problems with 802.1q tagged frames
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
` (5 preceding siblings ...)
2009-07-17 20:37 ` [patch 6/8] kernel/resource.c: fix sign extension in reserve_setup() Greg KH
@ 2009-07-17 20:37 ` Greg KH
2009-07-17 20:37 ` [patch 8/8] Dont use -fwrapv compiler option: its buggy in gcc-4.1.x Greg KH
[not found] ` <200907180329.34323.arekm@maven.pl>
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, Tomasz Lemiech, Ivan Vecera,
Ben McKeegan, Grant Grundler, Christoph Biedl, David S. Miller
[-- Attachment #1: tulip-fix-for-mtu-problems-with-802.1q-tagged-frames.patch --]
[-- Type: text/plain, Size: 9077 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Tomasz Lemiech <szpajder@staszic.waw.pl>
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 <szpajder@staszic.waw.pl>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Ben McKeegan <ben@netservers.co.uk>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/tulip/interrupt.c | 84 +++++++++++++++++++++++++++---------------
drivers/net/tulip/tulip.h | 32 +++++++++++++++-
2 files changed, 86 insertions(+), 30 deletions(-)
--- a/drivers/net/tulip/interrupt.c
+++ b/drivers/net/tulip/interrupt.c
@@ -140,6 +140,7 @@ int tulip_poll(struct napi_struct *napi,
/* If we own the next entry, it is a new packet. Send it up. */
while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) {
s32 status = le32_to_cpu(tp->rx_ring[entry].status);
+ short pkt_len;
if (tp->dirty_rx + RX_RING_SIZE == tp->cur_rx)
break;
@@ -151,8 +152,28 @@ int tulip_poll(struct napi_struct *napi,
if (++work_done >= budget)
goto not_done;
- if ((status & 0x38008300) != 0x0300) {
- if ((status & 0x38000300) != 0x0300) {
+ /*
+ * Omit the four octet CRC from the length.
+ * (May not be considered valid until we have
+ * checked status for RxLengthOver2047 bits)
+ */
+ pkt_len = ((status >> 16) & 0x7ff) - 4;
+
+ /*
+ * Maximum pkt_len is 1518 (1514 + vlan header)
+ * Anything higher than this is always invalid
+ * regardless of RxLengthOver2047 bits
+ */
+
+ if ((status & (RxLengthOver2047 |
+ RxDescCRCError |
+ RxDescCollisionSeen |
+ RxDescRunt |
+ RxDescDescErr |
+ RxWholePkt)) != RxWholePkt
+ || pkt_len > 1518) {
+ if ((status & (RxLengthOver2047 |
+ RxWholePkt)) != RxWholePkt) {
/* Ingore earlier buffers. */
if ((status & 0xffff) != 0x7fff) {
if (tulip_debug > 1)
@@ -161,30 +182,23 @@ int tulip_poll(struct napi_struct *napi,
dev->name, status);
tp->stats.rx_length_errors++;
}
- } else if (status & RxDescFatalErr) {
+ } else {
/* There was a fatal error. */
if (tulip_debug > 2)
printk(KERN_DEBUG "%s: Receive error, Rx status %8.8x.\n",
dev->name, status);
tp->stats.rx_errors++; /* end of a packet.*/
- if (status & 0x0890) tp->stats.rx_length_errors++;
+ if (pkt_len > 1518 ||
+ (status & RxDescRunt))
+ tp->stats.rx_length_errors++;
+
if (status & 0x0004) tp->stats.rx_frame_errors++;
if (status & 0x0002) tp->stats.rx_crc_errors++;
if (status & 0x0001) tp->stats.rx_fifo_errors++;
}
} else {
- /* Omit the four octet CRC from the length. */
- short pkt_len = ((status >> 16) & 0x7ff) - 4;
struct sk_buff *skb;
-#ifndef final_version
- if (pkt_len > 1518) {
- printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n",
- dev->name, pkt_len, pkt_len);
- pkt_len = 1518;
- tp->stats.rx_length_errors++;
- }
-#endif
/* Check if the packet is long enough to accept without copying
to a minimally-sized skbuff. */
if (pkt_len < tulip_rx_copybreak
@@ -357,14 +371,35 @@ static int tulip_rx(struct net_device *d
/* If we own the next entry, it is a new packet. Send it up. */
while ( ! (tp->rx_ring[entry].status & cpu_to_le32(DescOwned))) {
s32 status = le32_to_cpu(tp->rx_ring[entry].status);
+ short pkt_len;
if (tulip_debug > 5)
printk(KERN_DEBUG "%s: In tulip_rx(), entry %d %8.8x.\n",
dev->name, entry, status);
if (--rx_work_limit < 0)
break;
- if ((status & 0x38008300) != 0x0300) {
- if ((status & 0x38000300) != 0x0300) {
+
+ /*
+ Omit the four octet CRC from the length.
+ (May not be considered valid until we have
+ checked status for RxLengthOver2047 bits)
+ */
+ pkt_len = ((status >> 16) & 0x7ff) - 4;
+ /*
+ Maximum pkt_len is 1518 (1514 + vlan header)
+ Anything higher than this is always invalid
+ regardless of RxLengthOver2047 bits
+ */
+
+ if ((status & (RxLengthOver2047 |
+ RxDescCRCError |
+ RxDescCollisionSeen |
+ RxDescRunt |
+ RxDescDescErr |
+ RxWholePkt)) != RxWholePkt
+ || pkt_len > 1518) {
+ if ((status & (RxLengthOver2047 |
+ RxWholePkt)) != RxWholePkt) {
/* Ingore earlier buffers. */
if ((status & 0xffff) != 0x7fff) {
if (tulip_debug > 1)
@@ -373,31 +408,22 @@ static int tulip_rx(struct net_device *d
dev->name, status);
tp->stats.rx_length_errors++;
}
- } else if (status & RxDescFatalErr) {
+ } else {
/* There was a fatal error. */
if (tulip_debug > 2)
printk(KERN_DEBUG "%s: Receive error, Rx status %8.8x.\n",
dev->name, status);
tp->stats.rx_errors++; /* end of a packet.*/
- if (status & 0x0890) tp->stats.rx_length_errors++;
+ if (pkt_len > 1518 ||
+ (status & RxDescRunt))
+ tp->stats.rx_length_errors++;
if (status & 0x0004) tp->stats.rx_frame_errors++;
if (status & 0x0002) tp->stats.rx_crc_errors++;
if (status & 0x0001) tp->stats.rx_fifo_errors++;
}
} else {
- /* Omit the four octet CRC from the length. */
- short pkt_len = ((status >> 16) & 0x7ff) - 4;
struct sk_buff *skb;
-#ifndef final_version
- if (pkt_len > 1518) {
- printk(KERN_WARNING "%s: Bogus packet size of %d (%#x).\n",
- dev->name, pkt_len, pkt_len);
- pkt_len = 1518;
- tp->stats.rx_length_errors++;
- }
-#endif
-
/* Check if the packet is long enough to accept without copying
to a minimally-sized skbuff. */
if (pkt_len < tulip_rx_copybreak
--- a/drivers/net/tulip/tulip.h
+++ b/drivers/net/tulip/tulip.h
@@ -201,8 +201,38 @@ enum desc_status_bits {
DescStartPkt = 0x20000000,
DescEndRing = 0x02000000,
DescUseLink = 0x01000000,
- RxDescFatalErr = 0x008000,
+
+ /*
+ * Error summary flag is logical or of 'CRC Error', 'Collision Seen',
+ * 'Frame Too Long', 'Runt' and 'Descriptor Error' flags generated
+ * within tulip chip.
+ */
+ RxDescErrorSummary = 0x8000,
+ RxDescCRCError = 0x0002,
+ RxDescCollisionSeen = 0x0040,
+
+ /*
+ * 'Frame Too Long' flag is set if packet length including CRC exceeds
+ * 1518. However, a full sized VLAN tagged frame is 1522 bytes
+ * including CRC.
+ *
+ * The tulip chip does not block oversized frames, and if this flag is
+ * set on a receive descriptor it does not indicate the frame has been
+ * truncated. The receive descriptor also includes the actual length.
+ * Therefore we can safety ignore this flag and check the length
+ * ourselves.
+ */
+ RxDescFrameTooLong = 0x0080,
+ RxDescRunt = 0x0800,
+ RxDescDescErr = 0x4000,
RxWholePkt = 0x00000300,
+ /*
+ * Top three bits of 14 bit frame length (status bits 27-29) should
+ * never be set as that would make frame over 2047 bytes. The Receive
+ * Watchdog flag (bit 4) may indicate the length is over 2048 and the
+ * length field is invalid.
+ */
+ RxLengthOver2047 = 0x38000010
};
^ permalink raw reply [flat|nested] 12+ messages in thread* [patch 8/8] Dont use -fwrapv compiler option: its buggy in gcc-4.1.x
2009-07-17 20:39 ` [patch 0/8] 2.6.27.27-stable review Greg KH
` (6 preceding siblings ...)
2009-07-17 20:37 ` [patch 7/8] tulip: Fix for MTU problems with 802.1q tagged frames Greg KH
@ 2009-07-17 20:37 ` Greg KH
[not found] ` <200907180329.34323.arekm@maven.pl>
8 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-17 20:37 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: stable-review, torvalds, akpm, alan
[-- Attachment #1: don-t-use-fwrapv-compiler-option-it-s-buggy-in-gcc-4.1.x.patch --]
[-- Type: text/plain, Size: 1581 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Linus Torvalds <torvalds@linux-foundation.org>
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 <barryn@pobox.com>
Pushed-by: Frans Pop <elendil@planet.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Makefile
+++ b/Makefile
@@ -557,7 +557,7 @@ KBUILD_CFLAGS += $(call cc-option,-Wdecl
KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
# disable invalid "can't wrap" optimzations for signed / pointers
-KBUILD_CFLAGS += $(call cc-option,-fwrapv)
+KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
# But warn user when we do so
^ permalink raw reply [flat|nested] 12+ messages in thread[parent not found: <200907180329.34323.arekm@maven.pl>]
* Re: [patch 0/8] 2.6.27.27-stable review
[not found] ` <200907180329.34323.arekm@maven.pl>
@ 2009-07-20 3:48 ` Greg KH
0 siblings, 0 replies; 12+ messages in thread
From: Greg KH @ 2009-07-20 3:48 UTC (permalink / raw)
To: Arkadiusz Miskiewicz
Cc: linux-kernel, stable, stable-review, torvalds, akpm, alan
On Sat, Jul 18, 2009 at 03:29:34AM +0200, Arkadiusz Miskiewicz wrote:
> On Friday 17 of July 2009, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.27.27 release.
>
> Broken md patch that got applied in 2.6.27.26 should be reverted, see:
>
> http://lkml.org/lkml/2009/7/3/294
Ah, thanks for reminding me, I've now reverted this.
thanks again,
greg k-h
^ permalink raw reply [flat|nested] 12+ messages in thread