[IPV4]: ip_route_input panic fix (CVE-2006-1525)

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=6388
The bug is caused by ip_route_input dereferencing skb->nh.protocol of
the dummy skb passed dow from inet_rtm_getroute (Thanks Thomas for seeing
it). It only happens if the route requested is for a multicast IP
address.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SCTP]: Fix state table entries for chunks received in CLOSED state. (CVE-2006-2271)

Discard an unexpected chunk in CLOSED state rather can calling BUG().

Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: dann frazier <dannf@debian.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] Fix vfs_unlink issue introduced by link/unlink race correction

may_delete() should be called before attempting to grab victim's
i_zombie.

Signed-off-by: Marcelo Tosatti <marcelo@kvack.org>

[PATCH] JBD: avoid panic on corrupted journal superblock (from akpm)

Initial patch from Andrew Morton merged into 2.6 :
Don't panic if the journal superblock is wrecked: just fail the mount.

[PATCH] Fix memory leak when the ext3's journal file is corrupted

Fix memory leak when the ext3's journal file is corrupted

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

[NETFILTER]: SNMP NAT: fix memory corruption

Fix memory corruption caused by snmp_trap_decode:

- When snmp_trap_decode fails before the id and address are allocated,
  the pointers contain random memory, but are freed by the caller
  (snmp_parse_mangle).

- When snmp_trap_decode fails after allocating just the ID, it tries
  to free both address and ID, but the address pointer still contains
  random memory. The caller frees both ID and random memory again.

- When snmp_trap_decode fails after allocating both, it frees both,
  and the callers frees both again.

The corruption can be triggered remotely when the ip_nat_snmp_basic
module is loaded and traffic on port 161 or 162 is NATed.

Found by multiple testcases of the trap-app and trap-enc groups of the
PROTOS c06-snmpv1 testsuite.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] AMD Au1xx0: fix ethernet TX stats

With Au1xx0 Ethernet driver, TX bytes/packets always remain zero.

The problem seems to be that when packet has been transmitted, the
length word in DMA buffer is zero.

Attached is a patch that updates the TX stats when a buffer is fed to
DMA.

The initial 2.4 patch was posted to linux-mips@linux-mips.org by
Thomas Lange 21 Jan 2005.

Signed-off-by: Thomas Lange <thomas@corelatus.se>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

Vadim Egorov: ext3 link/unlink race

I found this issue with 2.4.27 kernel but I believe that other versions
are affected too.

The problem happens when link and unlink are invoked simultaneously on
the same inode on ext3 filesystem. In this case ext3_unlink may
decrement i_nlink to 0 and put this inode into the in-memory orphan
list, while ext3_link will increment i_nlink back to 1 having the inode
in the orphan list.

Thus the system ends up having an inode with i_nlink == 1 in the orphan
list.

When this inode gets unused later it the memory might get released to
the free pool and then be used for some other purpose, most likely some
other inode.

From this point on any operation on the orphan list may result in
modification of the list_head that could alredy be used to store some
other date.

Merge branch 'updates'

[PATCH] ide: trying to enable DMA may cause an oops

If DMA is disabled on the interface at boot time, then later calling
config_drive_for_dma() to try to enable it will cause an oops because
hwif->ide_dma_off_quietly will be NULL. The workaround is to make those
*ide_dma* functions point to a dummy one when DMA is disabled.

Originally reported by Glenn Wurster, and been running on my systems since
2.4.23.

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] drm: gcc complains that print_heap() in radeon_mem.c is not used.

print_heap() is declared static but not used anywhere. It could be removed,
but might be useful to someone for debugging purposes. Surrounding it with

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] netdrv: b44 driver must ignore carrier lost errors

some (?) hardware seems to be buggy and is reporting bogus carrier lost
values. Both reference implementations from Broadcom indicate that this
counter is not reliable and therefore ignore it. We should do the same.
"Fixes" the carrier lost problem i've seen.

Signed-off-by: Florian Schirmer <jolt@tuxbox.org>
Note: This patch was merged in 2.6 in early 2005.

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] netdrv: fix b44 loading after bcm4400

From Pekka Pietikain :

This patch makes the b44-after-bcm4400 scenario work for me. What
was happening is that the broadcom driver sets a "power off MAC"
bit, and we didn't remove that when initializing the chip. Also
added some (a bit ugly, I know  ) logic to clear up the address
filter stuff, which is what recent broadcom drivers do...

This fix was merged in 2.6 late in 2004, but did not receive any
echo for 2.4. At least it made the b44 driver usable on an Asus
Pundit for me.

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] 3c59x: reload EEPROM values at rmmod for needy cards

John W. Linville has posted this patch twice in the past, but it was merged
only in 2.6 and eventually got lost.

3c905 cards need an additional bit unmasked in the reset at rmmod or
else they don't get reinitialized properly when the driver is reloaded.
3c900 Boomerang added to list of devices needing EEPROM_RESET.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] fix mem-leak in netfilter

The Coverity checker spotted that we may leak 'hold' in
net/ipv4/netfilter/ipt_recent.c::checkentry() when the following
is true :
  if (!curr_table->status_proc) {
    ...
    if(!curr_table) {
    ...
      return 0;  <-- here we leak.
Simply moving an existing vfree(hold); up a bit avoids the possible leak.

(please keep me on CC when replying since I'm not subscribed
 to netfilter-devel)

Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>

[PATCH] scripts : ver_linux does not report recent binutils version

The 'ver_linux' script expects 'ld' to output a line starting with
'BFD', while recent versions of 'ld' print 'GNU ld'. The effect is
that binutils version is not listed in reports based on ver_linux.

The following trivial fix makes it do the right thing as 2.6 does.
Initially reported by Joshua Kwan. Tested and works.

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] block: remove the annoying 'blk: queue %p I/O limit %luMb' messages

This patch initially suggested by Matt Domsch seems to have got lost
in the noise. Its intent was to remove this annoying message that all
block devices print at boot. It was pure debugging and people still
take it for errors.

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] bonding: remove a warning with gcc 3

GCC 3 emits a warning on bond_alb:1278 because of a deprecated way
to cast a pointer in an assignment. This trivial fix silents it.

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] ext2: update inode ctime on rename()

The ext2fs filesystem on 2.2 and 2.6, as well as other filesystems
on 2.4 update the inode ctime on rename(). When this fix was applied
to 2.2.13, it was applied to the ext3 tree at the same time, but the
ext2 tree was forgotten. It was recently fixed in 2.6, but 2.4 was
forgotten again. Here's the fix.

First reported by Chris Siebenmann on 10 Jan 2004 !

Signed-off-by: Willy Tarreau <willy@w.ods.org>
- Willy

[PATCH] Neighbour Cache (ARP) State machine bug Fixed

In 2.4.21, arp code uses gc_timer to check for stale arp cache
entries. In 2.6, each entry has its own timer to check for stale arp
cache. 2.4.29 to 2.4.32 kernels (atleast) use neither of these timers.
This causes problems in environments where IPs or MACs are reassigned
- saw this problem on load balancing router based networks that use
VMACs. Tested this code on load balancing router based networks as
well as peer-linux systems.

Let me know if I need to contact someone else about this,

Thanks,

Pradeep Vincent

[PATCH] smbfs chroot issue (CVE-2006-1864)

Mark Moseley reported that a chroot environment on a SMB share can be
left via "cd ..\\".  Similar to CVE-2006-1863 issue with cifs, this fix
is for smbfs.

Steven French <sfrench@us.ibm.com> wrote:

Looks fine to me.  This should catch the slash on lookup or equivalent,
which will be all obvious paths of interest.

Back-ported to 2.4 by Willy Tarreau.
Signed-off-by: Willy Tarreau <willy@w.ods.org>

[PATCH] fix /proc/partitions display with USB-FDD geometry

When an USB flash disk is formatted under as a floppy (without partitions),
random partitions appear in /proc/partitions depending on the code and data
used by the boot loader at the offset where the partition table is expected :

   8     0     128000 sda
   8     1  985184692 sda1
   8     2  271759162 sda2
   8     3 1093808825 sda3
   8     4      26721 sda4

Such layout appears when Windows is used to format the USB stick, or when
putting a boot-loader such as syslinux on an device.

A patch was introduced in 2.6 to fix this by ensuring that all 4 partitions
boot flags are either 0x00 or 0x80 before interpreting the boot sector as an
MBR.

This fix has been back-ported to 2.4 by Gilles Espinasse. The behaviour has
been carefully tested, and 2.4.32 with this patch now behaves as 2.6.16 in
that such USB sticks are correctly detected without partitions, while others
still work correctly :

   8     0     128000 sda   => 128 MB USB stick formatted under windows
   8     0     261216 sdb   => 256 MB USB stick which contains a real partition
   8     1     261040 sdb1

Merge branch 'origin'

Contact information update

Fix printk length modifier of NFS mmap consistency patch

Change VERSION to v2.4.33-pre3

[PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards

Fixes Rhine I cards disclosing fragments of previously transmitted
frames in new transmissions.

Before transmission, any socket buffer (skb) shorter than the ethernet
minimum length of 60 bytes was zero-padded. On Rhine I cards the data
can later be copied into an aligned transmission buffer without copying
this padding. This resulted in the transmission of the frame with the
extra bytes beyond the provided content leaking the previous contents of
this buffer on to the network.

Now zero-padding is repeated in the local aligned buffer if one is used.

Following a suggestion from the via-rhine maintainer, no attempt is made
here to avoid the duplicated effort of padding the skb if it is known
that an aligned buffer will definitely be used. This is to make the
change "obviously correct" and allow it to be applied to a stable kernel
if necessary. There is no change to the flow of control and the changes
are only to the Rhine I code path.

Signed-off-by: Craig Brind <craigbrind@gmail.com>
Signed-off-by: Roger Luethi <rl@hellgate.ch>

[PATCH] i386/x86-64: Fix x87 information leak between processes

AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
when an exception is pending.  This means the value leak through
context switches and allow processes to observe some x87 instruction
state of other processes.

This was actually documented by AMD, but nobody recognized it as
being different from Intel before.

The fix first adds an optimization: instead of unconditionally
calling FNCLEX after each FXSAVE test if ES is pending and skip
it when not needed. Then do a dummy x87 load to clear FOP/FIP/FDP.
This means other processes always will only see a constant value
defined by the kernel.

Then it does a ffree st(7) ; fild <l1 address>
This is executed unconditionally on FXSAVE capable systems, but has
been benchmarked on Intel systems to be reasonably fast.

I also had to move unlazy_fpu for 64bit to make sure the code
always executes with the data segment of the new process to prevent
leaking the old one.

Patch for both i386/x86-64.

The problem was discovered originally by Jan Beulich. Richard
Brunner provided the basic code for the workarounds with contributions
from Jan.

This is CVE-2006-1056

Signed-off-by: Andi Kleen <ak@suse.de>

[PATCH] fix shm mprotect (CVE-2006-1524)

shmat stop mprotect from giving write permission to a readonly attachment.

Signed-off-by: Hugh Dickins <hugh@veritas.com>

[PATCH] fix /proc/partitions display with USB-FDD geometry

When an USB flash disk is formatted under as a floppy (without partitions),
random partitions appear in /proc/partitions depending on the code and data
used by the boot loader at the offset where the partition table is expected :

   8     0     128000 sda
   8     1  985184692 sda1
   8     2  271759162 sda2
   8     3 1093808825 sda3
   8     4      26721 sda4

Such layout appears when Windows is used to format the USB stick, or when
putting a boot-loader such as syslinux on an device.

A patch was introduced in 2.6 to fix this by ensuring that all 4 partitions
boot flags are either 0x00 or 0x80 before interpreting the boot sector as an
MBR.

This fix has been back-ported to 2.4 by Gilles Espinasse. The behaviour has
been carefully tested, and 2.4.32 with this patch now behaves as 2.6.16 in
that such USB sticks are correctly detected without partitions, while others
still work correctly :

   8     0     128000 sda   => 128 MB USB stick formatted under windows
   8     0     261216 sdb   => 256 MB USB stick which contains a real partition
   8     1     261040 sdb1

Merge w.ods.org/kernel/2.4/linux-2.4-upstream

[PATCH] x86-64: Always check that RIPs are canonical during signal handling (update)

Next try.

First the already existing check in COPY_CANON for sigreturn
wasn't correct. Replace it with a better check against TASK_SIZE.

Also add a check to sigaction which was missing it previously.

This works around a problem in handling non canonical RIPs on SYSRET on Intel
CPUs. They report the #GP on the SYSRET, not the next instruction
as Linux expects it. With these changes this path should never
see a non canonical user RIP.

I reset SIGSEGV to DFL to avoid an endless loop

Roughly based on a patch by Ernie Petrides, but redone by AK.

This is CVE-2006-0741

Cc: petrides@redhat.com
Signed-off-by: Andi Kleen <ak@suse.de>

[PATCH] e1000: Fix mii-tool access to setting speed and duplex

Paul Rolland reported that e1000 was having a hard time using
mii-tool to set speed and duplex. This patch initially from
Jesse Brandeburg backported from 2.6 fixes the issue on both
newer hardware as well as fixing the code issue that originally
caused the problem.

Signed-off-by: Willy Tarreau <willy@w.ods.org>

[PATCH] quota_v2 module taints the kernel (missing licence)

Apparently the quota_v2 module in 2.4 still lacks the licence macro
and taints the kernel, even though the same module in 2.6 is correctly
tagged as GPL. In case it makes things any easier, I am enclosing an
appropriate patch.

[PATCH] VLAN: Add two missing checks to vlan_ioctl_handler()

In vlan_ioctl_handler() the code misses couple checks for
error return values. The same patch was merged into 2.6.

Signed-of-by: Mika Kukkonen <mikukkon@iki.fi>

[PATCH] 2.4 nfs cache consistency problem with mmap'ed files

A customer of Red Hat reported a problem with cache invalidation when
using mmapped files over NFS with the 2.4 kernel. The steps to reproduce
this are a bit convoluted, so hopefully I'm explaining this well enough.
Let me know if you need clarification:

1) on a server create a file in an exported directory with some data in
it:

$ echo 1 > testfile

2) on an NFS client have a program mmap the file and access the data via
the mmap (effectively loading the pagecache with data from the server),
then have the program go to sleep indefinitely.

3) on the server, make a change to the file:

$ echo 2 > testfile

4) on the client, have another process cause a read:

$ cat /nfs/mounted/directory/testfile

You'll get the originally cached data (the 1), since the file is still
mmap'ed. This is expected.

5) on the client, kill the program that has the file mmap'ed and cat the
file again. You will still get the original file contents (the "1"
here).

The file is no longer mmap'ed, the data in the file and the mtime has
changed since the last on the wire read, but the client will not
invalidate the cache for subsequent reads.

What's happening is that in step 4, the __nfs_refresh_inode function
updates NFS_CACHE_MTIME. But, because the file is still mmap'ed,
invalidate_inode_pages is not completely successful. So on the next pass
through, it assumes the cached data is up to date when it isn't.

This patch fixes this by checking whether the clean_pages list
for the inode is empty after invalidate_inode_pages is called. If it's
not then we set a flag so on the next pass through it automatically
flags the data as invalid.

Signed-off-by: Jeff Layton <jtlayton@poochiereds.net>

[PATCH] Always check that RIPs are canonical during signal handling

First the already existing check in COPY_CANON for sigreturn
wasn't correct. Replace it with a better check against TASK_SIZE.

Also add a check to sigaction which was missing it previously.

This works around a problem in handling non canonical RIPs on SYSRET on Intel
CPUs. They report the #GP on the SYSRET, not the next instruction
as Linux expects it. With these changes this path should never
see a non canonical user RIP.

Roughly based on a patch by Ernie Petrides, but redone by AK.

This is CVE-2006-0741

Cc: petrides@redhat.com
Signed-off-by: Andi Kleen <ak@suse.de>

[PATCH] Fix small information leak in SO_ORIGINAL_DST and getname()

It appears sockaddr_in.sin_zero is not zeroed during certain operations
returning IPv4 socket names, namely:

- getsockopt(...SO_ORIGINAL_DST...) (2.4 and 2.6)
  see getorigdst() in net/ipv4/netfilter/ip_conntrack_core.c

- getsockname() and getpeername()
  see inet_getname() in net/ipv4/af_inet.c

A small patch for 2.4 fixing the problem is enclosed. Its first part
(fixing net/ipv4/af_inet.c) is identical to the change made in 2.6.

[PATCH] DRM: drm_stub_open() range checking

This patch corrects a bug in drm driver by forcing
its minor number in the limits of the allocated
resources: DRM(stub_list)[DRM_STUB_MAXCARDS]
       0<= minor < DRM_STUB_MAXCARDS.

Manifestation:    Xorg-6.9.0 SIGSEGFAULTs when the
loading of dri module is enabled (direct rendering)
Xorg-6.9.0 (and evidently not the previous versions)
has defined DRM_MAX_MINOR as 255 (and Xorg-6.9.0
tries to open all of them) while in the kernel:
DRM_STUB_MAXCARDS is defined as 16.

[PATCH] Corrected faulty syntax in drivers/input/Config.in

If statement in drivers/input/Config.in for "make xconfig" corrected.

Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

[PATCH] build fix: auto_fs4 changes broke ppc64 build

This patch adds a couple of #include statements verified to fix the compile
for ppc64 and probably will fix the compile on parisc.  I just noticed
parisc had the same problem.  ppc64 would not build without this fix.

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>

[PATCH] ip_queue: Fix wrong skb->len == nlmsg_len assumption

The size of the skb carrying the netlink message is not
equivalent to the length of the actual netlink message
due to padding. ip_queue matches the length of the payload
against the original packet size to determine if packet
mangling is desired, due to the above wrong assumption
arbitary packets may not be mangled depening on their
original size.

Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] x86_64: Check for bad elf entry address.

[Actually based on a 2.6 patch by Suresh Siddha, but the 2.4 implementation
is somewhat different]

Fixes a local DOS on Intel systems that lead to an endless
recursive fault.  AMD machines don't seem to be affected.

Signed-off-by: Andi Kleen <ak@suse.de>

[PATCH] PPC64: fix sys_rt_sigreturn() return type

While investigating a bug report about a 64bit application that crashed in
malloc, Paul Mackerras noticed that sys_rt_sigreturn's return value was
"int".  It needs to be "long" or else the return value of a syscall that
is interrupted by a signal will be truncated to 32 bits and then sign
extended.  This causes .e.g mmap's return value to be corrupted if it is
returning an address above 2^31 (which is what caused a SEGV in malloc).
This problem obviously only affects 64 bit processes.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

Change VERSION to 2.4.33-pre2

[PATCH] e1000: fix BUG reported due to calling msec_delay in irq context

There are some functions that are called in irq context that need to use
msec_delay_irq instead to avoid a BUG.

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> From: Stephan von Krawczynski <skraw@ithnet.com>
> today we had to experience a bug in e1000 network driver on this type of
> network card (a current PCI e1000 sold everywhere):
>
> 02:07.0 Ethernet controller: Intel Corp.: Unknown device 107c (rev 05)
>        Subsystem: Intel Corp.: Unknown device 1376
>        Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 18
>        Memory at f9000000 (32-bit, non-prefetchable) [size=128K]
>        Memory at f9020000 (32-bit, non-prefetchable) [size=128K]
>        I/O ports at a800 [size=64]
>        Expansion ROM at <unassigned> [disabled] [size=128K]
>        Capabilities: [dc] Power Management version 2
>        Capabilities: [e4] PCI-X non-bridge device.
>
> We can simply crash the box (2.4.32 stock kernel, 2.4.31 is the same) by
> performing this:
>
> 1) Boot box with network physically disconnected
> 2) start pinging some host somewhere, you get "unreachable", let it run
> 3) connect the network and await some ping replies.
> 4) disconnect the network again
> 5) box is dead
>
> The box runs into a BUG in e1000_hw.c line 5052. The BUG shows up because the
> code is obviously executed inside an interrupt, which seems not intended.
> As this BUG is always reproducable and pretty annoying we made this pretty bad
> workaround:

Please try this patch, compile tested.  It matches up this particular code
to what is currently in 2.6.16-rc

[PATCH] fix overflow in inode.c

The following patch fixes an overflow in inode.c.  This overflow can
cause a system to stop reclaiming inodes, with a large amount of memory
and zillions of inodes.  This has caused systems to run out of low
memory in real world situations.

Thanks go out to Larry Woodman, as well as the unnamed customer who
first tracked this problem down.  You know who you are.

Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Larry Woodman <lwoodman@redhat.com>

Merge w.ods.org/kernel/2.4/linux-2.4-upstream

[PATCH] orinoco: CVE-2005-3180: Information leakage due to incorrect padding

> [PATCH] Better fixup for the orinoco driver
>
> The latest kernel added a pretty ugly fix for the orinoco etherleak bug
> which contains bogus skb->len checks already done by the caller and causes
> copies of all odd sized frames (which are quite common)
>
> While the skb->len check should be ripped out the other fix is harder to do
> properly so I'm proposing for this the -mm tree only until next 2.6.x so
> that it gets tested.
>
> Instead of copying buffers around blindly this code implements a padding
> aware version of the hermes buffer writing function which does padding as
> the buffer is loaded and thus more cleanly and without bogus 1.5K copies.
>
> Signed-off-by: Alan Cox <alan@redhat.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>

The above is a patch included in 2.6.16 as a fix for CVE-2005-3180.  It to
be applicable to 2.4.  I have made a backport below, with the only
semi-significant change being including the ALIGN macro in orinoco.c, as it
doesn't exist in 2.4.

As yet untested

Signed-off-by: Horms <horms@verge.net.au>
index 0c06b14..b99edd3 100644

Merge branch 'master' of /data/projets/git/linux/linux-2.4

[PATCH] make 2.4.32 work on i486 again

Booting the 2.4.32 kernel compiled for a i486 on an i486 box fails,
because "Kernel compiled for Pentium+, requires TSC feature!" (printed
from check_config() include/asm-i386/bugs.h). To reproduce, select 486 in
the kernel configuration and grep CONFIG_X86_TSC .config

Alpha: fix recursive inlining failure in pci_iommu.c

From: Solar Designer <solar@openwall.com>

2.4.32 fails to build on my Alpha like this:

make[1]: Entering directory
`/stuff/owl-2006-1/usr/src/linux-2.4.32-ow1/arch/alpha/kernel'
gcc -D__KERNEL__ -I/stuff/owl-2006-1/usr/src/linux-2.4.32-ow1/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -fomit-frame-pointer -pipe -mno-fp-regs -ffixed-8 -mcpu=pca56
-Wa,-mev6   -nostdinc -iwithprefix include -DKBUILD_BASENAME=pci_iommu
-c -o pci_iommu.o pci_iommu.c
pci_iommu.c: In function `sg_fill':
pci_iommu.c:510: sorry, unimplemented: inlining failed in call to
'sg_fill': recursive inlining
pci_iommu.c:558: sorry, unimplemented: called from here
make[1]: *** [pci_iommu.o] Error 1

This is with gcc 3.4.5.  Simply removing the "inline" from the
declaration
of sg_fill() makes it build and work.

[SPARC]: Fix compile failures in math-emu.

Kill debugging default switch cases in do_one_mathemu().
That case is handled properly already and gcc hates
the empty statement that results when the debug code is
disabled.

Pointed out by kaffe.

Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of /data/projets/git/linux/linux-2.4

[PATCH] usb-uhci.c: wrong sign comparison in status check

urb->status should be compared to -ECONNRESET and not ECONNRESET.

Signed-off-by Guennadi Liakhovetski <g.liakhovetski@gmx.de>

[PATCH] proc_pid_cmdline() race fix (CAN-2004-1058)

The following patch fixes a race condition that allows local users to
view the environment variables of another process.

Taken from kernel-2.4.21-27.0.4.EL.src.rpm.

See:
http://linux.bkbits.net:8080/linux-2.6/cset@412a4baaEebwtKg-X7sS2r5Mua6uGw
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133113
http://lkml.org/lkml/2004/7/29/332

Signed-off-by: dann frazier <dannf@debian.org>

[PATCH] document that gcc 4 is not supported

gcc 4 is not supported for compiling kernel 2.4, and I don't see any
compelling reason why kernel 2.4 should ever be adapted to gcc 4.

This patch documents this fact.

Without this patch, your screen is flooded with warnings and errors when
accidentially trying to compile kernel 2.4 with gcc 4.

With this patch, the same happens, but the last lines contain the
explanation
  #error Sorry, your GCC is too recent for kernel 2.4

If someone makes a patch to fix all issues with gcc 4, adding the
removal of this #error should be the most trivial part of the patch.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

[PATCH] usbserial: using int for CPU flags is incorrect on x86_64

Using int for CPU flags is incorrect on x86_64.

PATCH: hash-table corruption in bond_alb.c

Hello,

Our systems have been crashing during testing of PCI HotPlug
support in the various networking components.  We've faulted in
the bonding driver due to a bug in bond_alb.c:tlb_clear_slave()

In that routine, the last modification to the TLB hash table is
made without protection of the lock, allowing a race that can lead
tlb_choose_channel() to select an invalid table element.

Our patch file is included below.

Thanks,
  --Michael O'Donnell, Stratus Technologies, Maynard, MA  USA

Signed-off-by: Michael O'Donnell <Michael.ODonnell at stratus dot com>

Documentation error 2.4.x aic7xxx

I found that documentation error after a mistake in my configuration file on
aic7xxx driver wich kept hanging at compile time.... I found my error and
that typofrom the error output of the kernel compilation.

The typo is in CONFIG_AIC7XXX_DEBUG_MASK ... it should say
CONFIG_AIC7XXX_DEBUG_ENABLE instead of CONFIG_AIC7XXX_DEBUG_ENBLE in the
Documentation/Configure.help file.

SAMSUNG CD-ROM SC-140 fails on DMA

Attempts to mount a SAMSUNG SC-140 CDROM are allowing DMA which fails.
User sees displayed
    mount: Directory not available

Adding { "SAMSUNG CD-ROM SC-140". "ALL" }. to the blacklist in
<linux>/drivers/ide/ide-dma.c
fixes the problem in Linux kernels 2.4.21 and newer (through 2.4.32).

[PATCH, 2.4] wan sdla: fix probable security hole

>  From: Chris Wright <chrisw@osdl.org>
>  Date: Mon, 19 Apr 2004 08:26:30 +0000 (-0400)
>  Subject: [PATCH] wan sdla:  fix probable security hole
>  X-Git-Tag: v2.6.6-rc2
>  X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=98cd917c1ac348d5cd94beabecc3011dcaa0a0f2
>
>  [PATCH] wan sdla:  fix probable security hole
>
>  > [BUG] minor
>  > /home/kash/linux/linux-2.6.5/drivers/net/wan/sdla.c:1206:sdla_xfer:
>  > ERROR:TAINT: 1201:1206:Passing unbounded user value "(mem).len" as arg 0
>  > to function "kmalloc", which uses it unsafely in model
>  > [SOURCE_MODEL=(lib,copy_from_user,user,taintscalar)]
>  > [SINK_MODEL=(lib,kmalloc,user,trustingsink)]  [MINOR]  [PATH=] [Also
>  > used at, line 1219 in argument 0 to function "kmalloc"]
>  > static int sdla_xfer(struct net_device *dev, struct sdla_mem *info, int
>  > read)
>  > {
>  >  struct sdla_mem mem;
>  >  char *temp;
>  >
>  > Start --->
>  >  if(copy_from_user(&mem, info, sizeof(mem)))
>  >  return -EFAULT;
>  >
>  >  if (read)
>  >  {
>  > Error --->
>  >  temp = kmalloc(mem.len, GFP_KERNEL);
>  >  if (!temp)
>  >  return(-ENOMEM);
>  >  sdla_read(dev, mem.addr, temp, mem.len);
>
>  Hrm, I believe you could use this to read 128k of kernel memory.
>  sdla_read() takes len as a short, whereas mem.len is an int.  So,
>  if mem.len == 0x20000, the allocation could still succeed.  When cast
>  to short, len will be 0x0, causing the read loop to copy nothing into
>  the buffer.  At least it's protected by a capable() check.  I don't
>  know what proper upper bound is for this hardware, or how much it's
>  used/cared about.  Simple memset() is trivial fix.

This seems to be applicable to 2.4

Signed-Off-By: Horms <horms@verge.net.au>

Merge /pub/scm/linux/kernel/git/davem/net-2.4

[IPV6] mcast: IPV6 side of IGMP DoS fix.

Same issue as IPv4, don't listen to non-broadcast
non-multicast reports.

Signed-off-by: David S. Miller <davem@davemloft.net>

[IGMP]: workaround for IGMP v1/v2 bug

From: David Stevens <dlstevens@us.ibm.com>

As explained at:

http://www.cs.ucsb.edu/~krishna/igmp_dos/

With IGMP version 1 and 2 it is possible to inject a unicast
report to a client which will make it ignore multicast
reports sent later by the router.

The fix is to only accept the report if is was sent to a
multicast or unicast address.

Signed-off-by: David S. Miller <davem@davemloft.net>

Change VERSION to 2.4.33-pre1

[PATCH] fs/smbfs/proc.c: fix data corruption in smb_proc_setattr_unix()

This patch fixes a data corruption in smb_proc_setattr_unix().

smb_filetype_from_mode() returns an u32, and there are only four bytes
reserved for it in data.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

Merge w.ods.org/kernel/2.4/linux-2.4-upstream

[PATCH] x86-64: user code panics kernel in exec.c (CVE-2005-2708)

There seems to be a local DoS in exec on AMD64 / linux 2.4
when the system is under memory pressure.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161925

Comment #9 From Dave Anderson    on 2005-08-31 14:36 EST

I don't particularly care for either patch suggestion. The problem is
that load_elf_binary() -- which is trying to load a legitimate ELF
binary, is returning -ENOEXEC back to search_binary_handler() because
load_elf_interp() has returned a BAD_ADDR:

        if (elf_interpreter) {
                if (interpreter_type == INTERPRETER_AOUT)
                        elf_entry = load_aout_interp(&interp_ex,
                                                     interpreter);
                else
                        elf_entry = load_elf_interp(&interp_elf_ex,
                                                    interpreter,
                                                    &interp_load_addr);

                if (BAD_ADDR(elf_entry)) {
                        printk(KERN_ERR "Unable to load interpreter\n");
                        send_sig(SIGSEGV, current, 0);
                        retval = -ENOEXEC; /* Nobody gets to see this, but.. */
                        goto out_free_dentry;
                }
                reloc_func_desc = interp_load_addr;

                allow_write_access(interpreter);
                fput(interpreter);
                kfree(elf_interpreter);
        }

and *because* search_binary_handler() sees the -ENOEXEC, it kicks off
the attempt to load the bogus module. And therein lies the problem, for
whatever reason, the modprobe process results in the double-fault, and
the original exec operation continues, and fails as it should. But that
all may be a red herring, since ENOEXEC with respect to execve means:

      ENOEXEC An  executable  is  not in a recognised format, is for the wrong
              architecture, or has some other format error that means it  can-
              not be executed.

However in this case, that's not at all true. It's legitimate, but the
attempt to load the /lib64/ld-linux-x86-64.so.2 interpreter into the
limited address space fails, and load_elf_interp() returns -ENOMEM. But
the ENOMEM is "lost" in the elf_entry variable. However, if -ENOMEM is
in fact returned back to search_binary_handler(), it all works just
fine. ENOMEM with respect to execve means:

       ENOMEM Insufficient kernel memory was available.

which isn't *exactly* what's going on here, but pretty close...

There's also the question of why the modprobe is failing, given that the
bogus module name doesn't exist. You would think that shouldn't cause
the kernel to double-fault. I mean do *all* of the request_module()
calls in the kernel require that the target module pre-exist? Since the
kernel seems to handle it differently/successfully on at least i386
and ia64, I haven't determined whether the request_module() is even
attempted on those architectures, or whether the operation fails in a
different code path.

[PATCH] usb: ehci in 2.4 with async_unlink

This is a long-standing problem. I had people hitting it from time to time,
but they would always go under instead of testing and reporting. Now one
gentleman reports stepping on this bug under simpler to reproduce conditions
than before. In his case, I/O stops when two DVD drives are connected
to the same bus.

I would like this to be in a test release after 2.4.32.

-- Pete

[SPARC64]: More fully work around Spitfire Errata 51.

It appears that a memory barrier soon after a mispredicted
branch, not just in the delay slot, can cause the hang
condition of this cpu errata.

Signed-off-by: David S. Miller <davem@davemloft.net>

[SPARC64]: Revamp Spitfire error trap handling.

Current uncorrectable error handling was poor enough
that the processor could just loop taking the same
trap over and over again.  Fix things up so that we
at least get a log message and perhaps even some register
state.

In the process, much consolidation became possible,
particularly with the correctable error handler.

Prefix assembler and C function names with "spitfire"
to indicate that these are for Ultra-I/II/IIi/IIe only.

More work is needed to make these routines robust and
featureful to the level of the Ultra-III error handlers.

Signed-off-by: David S. Miller <davem@davemloft.net>

[SPARC64]: Do not call winfix_dax blindly

Verify we really are taking a data access exception trap, at TL1, from
one of the window spill/fill handlers.

Else call a new function, data_access_exception_tl1, to log the error.

Signed-off-by: David S. Miller <davem@davemloft.net>

[SPARC64]: Fix trap state reading for instruction_access_exception.

1) Read ASI_IMMU SFSR not ASI_DMMU.
2) IMMU has no SFAR, read TPC instead
3) Delete old and incorrect comment about the DTLB protection
   trap having a dependency on the SFSR contents in order to
   function correctly

Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH] Fix SATA update KM_IRQ issue with highmem

On Tue, Dec 13, 2005 at 12:04:51AM -0500, Jeff Garzik wrote:
> Best place to add compat defines/enums such as the proposed is
> include/linux/libata-compat.h.

This seems fair to me, particularly since it does not exist in 2.6. I've
checked that there does not seem to exist any file included after it which
need to know about kmap types (even on ia64), so it should be safe to
redefine KM_IRQ0 in libata-compat.h.

[PATCH] local denial-of-service with file lease

    [PATCH] VFS: local denial-of-service with file leases

    Remove time_out_leases() printk that's easily triggered by users.

Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Above is the signoff information for
    f3a9388e4ebea57583272007311fffa26ebbb305 included in Linus's 2.6 tree.
    As this is CVE-2005-3857 I am proposing its inclusion in 2.4

Signed-off-by: Horms <horms@verge.net.au>

[PATCH] MTD: kernel stuck in tight loop occasionally on flash access

We are running a Timesys modified version of the 2.4 kernel.
Occasionally we see board lockups on heavy file system and direct MTD
flash accesses. I have traced this down to a bug in the 2.4 MTD code
(chip driver to be specific) and see this problem even in the latest 2.4
kernel (2.4.32). I realize that this problem may not be seen by others
using the stock kernel, but I think it needs to be fixed anyway for
correctness.

The problem is in cfi_cmdset_0001.c, and is present in drivers for other
chips as well. In the function cfi_intelext_sync() function before
calling schedule(), the current process needs to be put to sleep by
calling set_current_state(TASK_UNINTERRUPTIBLE). If it is not put to
sleep, the task remains in the run queue of the kernel and if its
priority is high enough, the kernel will constantly keep scheduling this
process, the state of the chip will never change.

Adding this one line seems to make our lockups go away. There were
questions raised as to why TASK_UNINTERRUPTIBLE. The same driver uses
TASK_UNINTERRUPTIBLE in other similar places while waiting for hardware
to complete erasing etc. I chose the same thing.

I am not subscribed to the mailing list, so please CC me on any replies.

Signed-off-by: Vijay Sampath <vijay.sampath@aktino.com>

[PATCH] dcache: avoid race when updating nr_unused count of unused dentries

 ChangeSet
   2004/05/29 10:58:56-07:00 akpm@osdl.org
   [PATCH] fs/dcache.c: avoid race when updating nr_unused count of unused dentries.

   From: NeilBrown <neilb@cse.unsw.edu.au>

   d_count == 1 is no guarantee that dentry is on the dentry_unused list, even
   if it has just been incremented inside dcache_lock, as dput can decrement
   at any time.

   This test from Greg Banks is much safer, and is more transparently correct.

Cc: Maneesh Soni <maneesh@in.ibm.com>, Dipankar Sarma <dipankar@in.ibm.com>
   From: Greg Banks <gnb@melbourne.sgi.com>
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

[PATCH] Fix sendmsg overflow (CVE-2005-2490)

Al Viro reported a flaw in sendmsg(). "When we copy 32bit ->msg_control
contents to kernel, we walk the same userland data twice without sanity
checks on the second pass. Moreover, if original looks small enough, we
end up copying to on-stack array."

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2490

Acked-by: okir@suse.de

[PATCH] ide: add recent ATI IXP300/400 PATA support

This patch just adds recent ATI IXP300/400 ATA133 controler to ide, atiixp.c
for 2.4 kernel.

People in my lab been using it for a while and seems to have no problem,
so I decided to post it here.

Signed-off-by: Akira Tsukamoto <akira-t@s9.dion.ne.jp>
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

[PATCH] aic7xxx: reset handler selects a wrong command

To transport scsi reset command to device aic7xxx reset handler looks at
the driver's pending_list and searches any proper command. However the
search condition has been inverted: ahc_match_scb() returns TRUE if a
matched command is found.

As a result the reset on required devices did not turn out well, a
correctly working neighbour device may be surprised by the reset.
aic7xxx reset handler reports about the success, but really the original
situation is not corrected yet.

The problem has been found first on 2.4 kernels but still it is present in
latest 2.6 drivers too.

[SCSI] aic7xxx: reset handler selects a wrong command

To transport scsi reset command to device aic7xxx reset handler looks at the
driver's pending_list and searches any proper command. However the search
condition has been inverted: ahc_match_scb() returns TRUE if a matched command
is found.
As a result the reset on required devices did not turn out well, a correctly
working neighbour device may be surprised by the reset. aic7xxx reset handler
reports about the success, but really the original situation is not corrected yet.

Signed-off-by: Vasily Averin <vvs@sw.ru>

[PATCH] IPv6: fix refcnt of struct ip6_flowlabel

This looks like another potential "local DoS" since this is in
setsockopt(IPV6_FLOWLABEL_MGR). Users can cause a flow label to be
kfreed() without removing it from the socket; and then overwrite its
contents. This can trigger random kernel memory corruption.

Acked-by: okir@suse.de

[PATCH] Fix ptrace self-attach rule (2.6 backport)

Patch-mainline: v2.6.14.2
Acked-by: Karsten Keil <kkeil@suse.de>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.14.y.git;a=commitdiff;h=082d52c56f642d21b771a13221068d40915a1409

  [PATCH] Fix ptrace self-attach rule

  Before we did CLONE_THREAD, the way to check whether we were attaching
  to ourselves was to just check "current == task", but with CLONE_THREAD
  we should check that the thread group ID matches instead.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>

[PATCH] IPv6: small fix for ip6_mc_msfilter

Multicast source filters aren't widely used yet, and that's really
the only feature that's affected if an application actually exercises
this bug, as far as I can tell. An ordinary filter-less multicast join
should still work, and only forwarded multicast traffic making use of
filters and doing empty-source filters with the MSFILTER ioctl would
be at risk of not getting multicast traffic forwarded to them because
the reports generated would not be based on the correct counts.
Initial 2.6 patch by Yan Zheng, bug explanation by David Stevens,
patch ACKed by David.

Signed-off-by: Willy Tarreau <willy@w.ods.org>

[libata] fix potential oops in pdev_printk() compat helper

[libata] fix build

[libata] resync with 2.6.15-rc3

* ->host_stop() cleanups
* remove ata_chk_err(), ->chk_err()
* many ATAPI fixes
* error handling fixes
* use stub pci_set_consistent_dma_mask(), for easier sync with 2.6.x
* use pdev_printk() for easier sync with 2.6.x dev_printk()
* PATA updates (unused for now)
* PIO updates
* ATA passthru support
* new PCI IDs

[libata] resync with 2.6.14

* Change license from OSL+GPL to GPL
* Minor additions for new hardware support
* Minor bug fixes
* __iomem markers
* EH locking cleanup (note, causes bug, which will be fixed in later cset)
* use generic pci_intx()
* use pci_iomap(), pci_iounmap()
* ata_piix: fix probe
* 'atapi_enabled' module option, replaces #define
* PIO data xfer fixes
* ATAPI interrupt handling fixes
* support START STOP UNIT scsi command
* scsi READ/WRITE translation edge case fixes
* sata_sil: go faster, on controllers without mod15write support

[libata sata_sx4] trim trailing whitespace

Preparation for resync with 2.6.14.

[libata] resync with kernel 2.6.13

Minor update, no major changes/fixes.

ahci: add MODULE_VERSION()
ata_piix: disable AHCI if active
sata_sx4: fix DMA length setting bug
bump libata/driver versions where appropriate

[PATCH] fix for clock running too fast

This one line patch adds upper bound testing inside timer_irq_works()
when evaluating whether irq timer works or not on boot up.

It fix the machines having problem with clock running too fast.

What this patch do is, if timer interrupts running too fast through
IO-APIC IRQ then false back to i8259A IRQ.

Signed-off-by: Akira Tsukamoto <akira-t@s9.dion.ne.jp>
Acked-by: Ingo Molnar <mingo@elte.hu>

[PATCH] drivers/scsi/dpt_i2o.c: fix a NULL pointer dereference

The Coverity checker spotted this obvious NULL pointer dereference.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Mark Salyzyn <mark_salyzyn@adaptec.com>
 drivers/scsi/dpt_i2o.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

[PATCH] NFS server as a module with -mregparm=3

This patch makes it possible to compile the nfs server as a module, with
-mregparm=3 (at least on x86).

Such a combination did not work, as handle_sys_nfsservctl was called
from the sys_nfsservctl function (in fs/filesystems.c) with parameters
in registers, but tried to read them from the stack.

Signed-off-by: Krzysztof Strasburger

[PATCH] Don't panic on IDE DMA errors

Kernel 2.4.32 and earlier can panic when trying to read a corrupted
sector from an IDE disk.

The function ide_dma_timeout_retry can end a request early by calling
idedisk_error, but then goes on to use the request anyway causing a
kernel panic due to a null pointer exception. This patch fixes that.

[PATCH] Backport of CVE-2005-2709 fix

 I've backported the fix for CVE-2005-2709 to 2.4 for Debian's 2.4
sarge kernel. Below is a patch against 2.4.32, in case one hasn't been
submitted to you yet. Please apply.

CVE-2005-2709

sysctl.c in Linux kernel before 2.6.14.1 allows local users to cause a
denial of service (kernel oops) and possibly execute code by opening an
interface file in /proc/sys/net/ipv4/conf/, waiting until the interface
is unregistered, then obtaining and modifying function pointers in
memory that was used for the ctl_table.

Signed-off-by: dann frazier <dannf@debian.org>

[PATCH] Reintroduction i386 CONFIG_DUMMY_KEYB option

This re-activates an option making it possible to replace the PS2
keyboard driver by a dummy one still compatible with CONFIG_VT. The code
has been in the kernel for a long time, only the option was hidden ! It
also has an equivalent in 2.6.

Patch from Nick Warne <nick@linicks.net>
Signed-off-by: Willy Tarreau <willy@w.ods.org>

[PATCH] airo.c/airo_cs.c: correct prototypes

This patch creates a file airo.h containing prototypes of the global
functions in airo.c used by airo_cs.c .

If you got strange problems with either airo_cs devices or in any other
completely unrelated part of the kernel shortly or long after a airo_cs
device was detected by the kernel, this might have been caused by the
fact that caller and callee disagreed regarding the size of the first
argument to init_airo_card()...

A similar patch was already included in Linus' 2.6 tree.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

[PATCH] sis900: come alive after temporary memory shortage (fixed version)

I would like to inform you that unfortunately the committed patch is wrong
http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=ecf3337f76eaa94c5a771308d184dc248b74b725

+ int rx_work_limit =
+ (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;

when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC

Could you please drop the wrong patch and use a new one based on the version
approved by Daniele Venzano and Jeff Garzik
http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff_plain;h=7380a78a973a8109c13cb0e47617c456b6f6e1f5;hp=b2795f596932286ef12dc08857960d654f577405

  sis900: come alive after temporary memory shortage

  1) Forgotten counter incrementation in sis900_rx() in case
       it doesn't get memory for skb, that leads to whole interface failure.
       Problem is accompanied with messages:
      eth0: Memory squeeze,deferring packet.
      eth0: NULL pointer encountered in Rx ring, skipping

  2) If counter cur_rx overflows and there'll be temporary memory problems
       buffer can't be recreated later, when memory IS available.

  3) Limit the work in handler to prevent the endless packets processing
     if new packets are generated faster then handled.

Signed-off-by: Konstantin Khorenko <khorenko@sw.ru>
Signed-off-by: Vasily Averin <vvs@sw.ru>

Revert broken sis900 update

[PATCH] sis900: come alive after temporary memory shortage

Patch solves following problems:
1) Forgotten counter incrementation in sis900_rx() in case
      it doesn't get memory for skb, that leads to whole interface failure.
      Problem is accompanied with messages:
     eth0: Memory squeeze,deferring packet.
     eth0: NULL pointer encountered in Rx ring, skipping
2) If counter cur_rx overflows and there'll be temporary memory problems
      buffer can't be recreated later, when memory IS avaliable.
3) Limit the work in handler to prevent the endless packets processing if
      new packets are generated faster then handled.

Signed-off-by: Konstantin Khorenko <khorenko@sw.ru>
Signed-off-by: Vasily Averin <vvs@sw.ru>