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>

[PATCH] add Pioneer DRM-624X to drivers/scsi/scsi_scan.c

The patch below made my Pioneer DRM-624X automatically be set up with
all 6 "drives". (6 slot SCSI CD changer). My DRM-604X already worked
this way already.

Already merged into v2.6.

Signed-off-by: Karl Magnus Kolstø <karl.kolsto@uib.no>

Change VERSION to v2.4.32

Change VERSION to 2.4.32-rc3

[PATCH] only disallow _setting_ of function key string

Mikael Pettersson <mikpe@csd.uu.se> noted that the current 2.6-git (and
2.4) patch to disallow KDSKBSENT for unpriviledged users should be less
restrictive allowing reading of current function key string entry, but
not writing.

Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>

[PATCH] fix missing refcnt put with expire_nodest_conn

It seems we forgot to fix one place where ip_vs_conn_expire_now
is used. Callers should hold write lock or cp->refcnt (and not forget
it). This results in hanging template entries when expire_nodest_conn is
kicking in and trying to remove all connection entries for a specific
destination.

Julian Anastasov created a patch to fix this and asked me to forward it
for inclusion, after test and verification, which have happened the last
24 hours.

This problem also exists in 2.6.x kernels, patch will be sent to netdev.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Roberto Nibali <ratz@drugphish.ch>

Change VERSION to 2.4.32-rc2

[PATCH] fix memory leak in sd_mod.o

Handle freeing of sd_max_sectors in sd_exit().

Signed-off-by: Dan Aloni <da-x@monatomic.org>

[PATCH] Clear stale pred_flags when snd_wnd change

This bug is responsible for causing the infamous "Treason uncloaked"
messages that's been popping up everywhere since the printk was added.
It has usually been blamed on foreign operating systems.  However,
some of those reports implicate Linux as both systems are running
Linux or the TCP connection is going across the loopback interface.

In fact, there really is a bug in the Linux TCP header prediction code
that's been there since at least 2.1.8.  This bug was tracked down with
help from Dale Blount.

The effect of this bug ranges from harmless "Treason uncloaked"
messages to hung/aborted TCP connections.  The details of the bug
and fix is as follows.

When snd_wnd is updated, we only update pred_flags if
tcp_fast_path_check succeeds.  When it fails (for example,
when our rcvbuf is used up), we will leave pred_flags with
an out-of-date snd_wnd value.

When the out-of-date pred_flags happens to match the next incoming
packet we will again hit the fast path and use the current snd_wnd
which will be wrong.

In the case of the treason messages, it just happens that the snd_wnd
cached in pred_flags is zero while tp->snd_wnd is non-zero.  Therefore
when a zero-window packet comes in we incorrectly conclude that the
window is non-zero.

In fact if the peer continues to send us zero-window pure ACKs we
will continue making the same mistake.  It's only when the peer
transmits a zero-window packet with data attached that we get a
chance to snap out of it.  This is what triggers the treason
message at the next retransmit timeout.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[PATCH] Fix infinite loop in udp_v6_get_port()

    [IPV6]: Fix infinite loop in udp_v6_get_port()

    This is CVE-2005-2973, and
    87bf9c97b4b3af8dec7b2b79cdfe7bfc0a0a03b2 in Linus' 2.6 Git Tree.
    It seems to be relevant to 2.4

    [IPV6]: Fix infinite loop in udp_v6_get_port()

    Original sign-off

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
    Mine, indicating that I think it is relevant to 2.4

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

[PATCH] loadkeys requires root priviledges

Signed-off-by: Andrew Morton <akpm@osdl.org>

[PATCH] possible memory ordering bug in page reclaim

Is there anything that prevents PageDirty from theoretically being
speculatively loaded before page_count here? (see patch)

It would result in pagecache corruption in the following situation:

1                                2
find_get_page();
write to page                    write_lock(tree_lock);
SetPageDirty();                  if (page_count != 2
put_page();                          || PageDirty())

Now I'm worried that 2 might see PageDirty *before* SetPageDirty in
1, and page_count *after* put_page in 1.

[PATCH] AX.25: signed char bug

Date: Oct 14, 2005 6:29 PM

On architectures where the char type defaults to unsigned some of the
arithmetic in the AX.25 stack to fail, resulting in some packets being
dropped on receive.

Credits for tracking this down and the original patch to
Bob Brose N0QBJ <linuxhams@n0qbj-11.ampr.org>.

Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>

[PATCH] usb: regression in usb-ohci

My fix for a problem in usb-ohci in 2.4.28 was simply broken.

The original problem was that the interrupt handler referenced an area below
a process' stack pointer, which worked everywhere except ia64. On ia86 such
practice causes a CPU trap.

I "fixed" it by moving the wait queue head to a place ... which was
freed immediately afterwards. I really have no idea what I was thinking.
It's not even a race of any sort, the code references a freed area
completely in sequence.

This patch is a sort of a two-step. First, it undoes what I did and returns
to the code in 2.4.27. Next, it puts a spinlock around the remove_wait_queue.
This ought to be safe for the vast majority of systems, and possibly fixes
the issue with ia64 (it was sort of hard to reproduce: it only happened on
an Altix).

My testing was light, but since the fix mostly reverts the broken patch,
I think it can go into the next test, -pre, or -rc release.

-- Pete

[PATCH] asus vt8235 router buggy bios workaround

Here is backport to 2.4 for fix to
http://bugzilla.kernel.org/show_bug.cgi?id=5235.

Similar problem has been reported before here:
http://groups.google.com/group/linux.kernel/browse_thread/thread/def4ca1
9dbc3cd4/5cffbf349f2c87a4?tvc=2&q=Aleksey+Gorelov&hl=en#5cffbf349f2c87a4
and was related to bug in BIOS reporting 82C686 router compatible to
586.

I suspect BIOS on this board has similar issue: reports VT8235 router to
be compatible with 586 one - which is obviously not true. Patch from the
link above has already incorporated in both 2.6 & 2.4 series, but might
not work in this particular case.

Signed-off-by: Aleksey Gorelov <aleksey_gorelov@phoenix.com>

[PATCH] Fix jiffies overflow in delay.h

There are several multiply overflows in delay.h:msecs_to_jiffies(). The
first one is the call to jiffies_to_msecs(MAX_JIFFY_OFFSET) which will
multiply MAX_JIFFY_OFFSET by (1000/HZ) or by 1000 during conversion,
while it was already high (~0UL>>1)-1 ... Needless to say that it's
wrong below 500 HZ and for all values not multiple of 1000 or which
don't divide 1000.

The second overflow can happen a few lines later, but this time on the
argument. The fix consists in defining a constant (macro) which depends
on HZ and fixes the absolute maximal value which we guarantee will not
produce an overflow. Fortunately, I've found no user of msecs_to_jiffies()
in mainline, although sys_poll() could benefit from it in order to avoid
a useless divide in the fast path.

But I think that the code needs be fixed anyway, considering that it
had been inherited by 2.6 for which I proposed the same fix. And it
is possible that some external patches use it.

[IPVS]: Add netdev and me as maintainer contacts

Signed-off-by: Horms <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

[NETFILTER]: this patch fixes a compilation issue with gcc 3.4.3.

Signed-off-by: Marcus Sundberg <marcus@ingate.com>
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[MCAST]: Fix MCAST_EXCLUDE line dupes

Signed-off-by: Denis Lukianov <denis@voxelsoft.com>
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPVS]: really invalidate persistent templates

Agostino di Salle noticed that persistent templates are not
invalidated due to buggy optimization.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPVS]: ip_vs_ftp breaks connections using persistence

ip_vs_ftp when loaded can create NAT connections with unknown
client port for passive FTP. For such expectations we lookup with
cport=0 on incoming packet but it matches the format of the persistence
templates causing packets to other persistent virtual servers to be
forwarded to real server without creating connection. Later the
reply packets are treated as foreign and not SNAT-ed.

This patch changes the connection lookup for packets from
clients:

* introduce IP_VS_CONN_F_TEMPLATE connection flag to mark the
connection as template
* create new connection lookup function just for templates - ip_vs_ct_in_get
* make sure ip_vs_conn_in_get hits only connections with
IP_VS_CONN_F_NO_CPORT flag set when s_port is 0. By this way
we avoid returning template when looking for cport=0 (ftp)

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>

[TCP]: Don't over-clamp window in tcp_clamp_window()

From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>

Handle better the case where the sender sends full sized
frames initially, then moves to a mode where it trickles
out small amounts of data at a time.

This known problem is even mentioned in the comments
above tcp_grow_window() in tcp_input.c, specifically:

...
 * The scheme does not work when sender sends good segments opening
 * window and then starts to feed us spagetti. But it should work
 * in common situations. Otherwise, we have to rely on queue collapsing.
...

When the sender gives full sized frames, the "struct sk_buff" overhead
from each packet is small.  So we'll advertize a larger window.
If the sender moves to a mode where small segments are sent, this
ratio becomes tilted to the other extreme and we start overrunning
the socket buffer space.

tcp_clamp_window() tries to address this, but it's clamping of
tp->window_clamp is a wee bit too aggressive for this particular case.

Fix confirmed by Ion Badulescu.

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

[PATCH] CAN-2005-0204: AMD64, allows local users to write to privileged IO ports via OUTS instruction

Description: [CAN-2005-0204]: AMD64, allows local users to write to privileged IO ports via OUTS instruction
Patch author: Suresh Siddha (suresh.b.siddha@intel.com)
Upstream status: not applied
URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146244
Patch source: Micah Anderson <micah@riseup.net> (debian-kernel)

Added definition of IO_BITMAP_BYTES for Debian's 2.4.27 and
submitted upstream for consideration for inclusion in 2.4 -- Horms

NFS: dprintk on -ENAMETOOLONG error handling

[PATCH] nfs client: handle long symlinks properly

In 2.4.31, the v2/3 nfs readlink accepts too long symlinks.
I have tested this by having a server return long symlinks.

diff -u linux-2.4.31.orig/fs/nfs/nfs2xdr.c linux-2.4.31/fs/nfs/nfs2xdr.c

[PATCH] Update PPPoE's configuration documentation

Following trivial patch updates the CONFIG_PPPOE options's
documentation.

o Update CONFIG_PPPOE option's documentation since ppp version
   2.4.2 is already released (with PPPoE plug-in) and there is
   no need a CVS checkout anymore

Signed-off-by: M.Baris Demiray <baris@labristeknoloji.com>
diff --git a/Documentation/Configure.help b/Documentation/Configure.help

[PATCH] IA64: page_not_present fault in region 5 is normal

Attached is a patch for the latest 2.4 tree
which is semantically identical to what was included in 2.6.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=63028aa7f581d9d4e6889f9dc06ded2534250a76

Without this patch, exception handler can be unexpectedly invoked for
page-not-present fault in region 5 and cause panic etc.

Could you apply the attached patch to 2.4?
We tested the patch on 2.4.29 + linux-2.4.29-ia64-050312 patch
which is the latest version working on ia64.

Excerpt from ChangeLog-2.6.14-rc1:

When copying data from user-space to kernel-space by __copy_user(),
a page_not_present fault sometimes occurs at vmalloced kernel address
because of VHPT pre-fetching.

Ignore the page_not_present fault in ia64_do_page_fault() before
jumping into exception handlers.

Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
diff --git a/arch/ia64/mm/fault.c b/arch/ia64/mm/fault.c

Update VERSION to 2.4.32-rc1

[PATCH] Lost sockfd_put() in routing_ioctl()

This patch adds lost sockfd_put() in 32bit compat rounting_ioctl() on
64bit platforms

I believe this is a security issues, since user can fget() file as many
times as he wants to. So file refcounter can be overlapped and first
fput() will free resources though there will be still structures
pointing to the file, mnt, dentry etc.
Also fput() sets f_dentry and f_vfsmnt to NULL,
so other file users will OOPS.

The oops can be done under files_lock and others, so this can be an
exploitable DoS on SMP. Didn't checked it on practice actually.

Signed-Off-By: Kirill Korotaev <dev@sw.ru>
Signed-Off-By: Maxim Giryaev <gem@sw.ru>
diff --git a/arch/ppc64/kernel/ioctl32.c b/arch/ppc64/kernel/ioctl32.c

[PATCH] lost fput in 32bit ioctl on x86-64

This patch adds lost fput in 32bit tiocgdev ioctl on x86-64

I believe this is a security issues, since user can fget() file as many
times as he wants to. So file refcounter can be overlapped and first
fput() will free resources though there will be still structures
pointing to the file, mnt, dentry etc.
Also fput() sets f_dentry and f_vfsmnt to NULL,
so other file users will OOPS.

The oops can be done under files_lock and others, so this is really
exploitable DoS on SMP. Didn't checked it on practice actually.

Signed-Off-By: Kirill Korotaev <dev@sw.ru>
Signed-Off-By: Maxim Giryaev <gem@sw.ru>
diff --git a/arch/x86_64/ia32/ia32_ioctl.c b/arch/x86_64/ia32/ia32_ioctl.c

[NETFILTER]: Handle NAT module load race

When the NAT module is loaded when connections are already confirmed
it must not change their tuples anymore. This is especially important
with CONFIG_NETFILTER_DEBUG, the netfilter listhelp functions will
refuse to remove an entry from a list when it can not be found on
the list, so when a changed tuple hashes to a new bucket the entry
is kept in the list until and after the conntrack is freed.

Allocate the exact conntrack tuple for NAT for already confirmed
connections or drop them if that fails.

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

[PATCH] Andrea Arcangeli: avoid size_buffers_type overflow

size_buffers_type array, which is an unsigned long, can overflow
on 32-bits: its perfectly possible for PAE machines to have more
than 4Gb of data mapped by buffer_head's at the same time.

Avoid that by accounting 1/512 of the real size (size >> 9).

[PATCH] i386: fix incorrect FP signal delivery

i386 floating-point exception handling has a bug that can cause error
code 0 to be sent instead of the proper code during signal delivery.

This is caused by unconditionally checking the IS and c1 bits from the
FPU status word when they are not always relevant.  The IS bit tells
whether an exception is a stack fault and is only relevant when the
exception is IE (invalid operation.) The C1 bit determines whether a
stack fault is overflow or underflow and is only relevant when IS and IE
are set.

diff --git a/arch/i386/kernel/traps.c b/arch/i386/kernel/traps.c

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

[IPV4]: Fix negative timer loop with lots of ipv4 peers.

From: Dave Johnson <djohnson+linux-kernel@sw.starentnetworks.com>

Found this bug while doing some scaling testing that created 500K inet
peers.

peer_check_expire() in net/ipv4/inetpeer.c isn't using inet_peer_gc_mintime
correctly and will end up creating an expire timer with less than the
minimum duration, and even zero/negative if enough active peers are
present.

If >65K peers, the timer will be less than inet_peer_gc_mintime, and with
>70K peers, the timer duration will reach zero and go negative.

The timer handler will continue to schedule another zero/negative timer in
a loop until peers can be aged.  This can continue for at least a few
minutes or even longer if the peers remain active due to arriving packets
while the loop is occurring.

Bug is present in both 2.4 and 2.6.  Same patch will apply to both just
fine.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SPARC64]: Use vmalloc() in do_netfilter_replace()

Otherwise the number of rules one can upload into the kernel
is severely limited.

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

[PATCH] cciss 2.4.60

This patch
        1) adds support for next series of Smart Array contollers.
        2) bumps version to 2.4.60.
        3) changes our copyright dates.
        4) adds code to bind to any HP controller with a cciss signature.
Built against 2.4.31. Please consider this for inclusion.

Signed-off-by: Mike Miller
 Documentation/cciss.txt |    6 ++++
 drivers/block/cciss.c   |   60 ++++++++++++++++++++++++++++++++++++++----------
 include/linux/pci_ids.h |    4 +++
 3 files changed, 57 insertions(+), 13 deletions(-)

[IPV6]: Route events reported with wrong netlink PID and seq number

Attached is backport of patch from jamal already in the 2.6 kernel -
It would be very nice to see it in the 2.4 kernel as well, as I keep
receiving reports from users that "Quagga IPv6 is broken with 2.4 kernel".

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

Revert unnecessary arch/ppc64/boot/zlib.c

It turns out that empty distance code tables are not an error, and that
a compressed block with only literals can validly have an empty table
and should not be flagged as a data error.

Some old versions of gzip had problems with this case, but it does not
affect the zlib code in the kernel.

Analysis and explanations thanks to Sergey Vlasov <vsu@altlinux.ru>

Revert unnecessary zlib_inflate/inftress.c fix

It turns out that empty distance code tables are not an error, and that
a compressed block with only literals can validly have an empty table
and should not be flagged as a data error.

Some old versions of gzip had problems with this case, but it does not
affect the zlib code in the kernel.

Analysis and explanations thanks to Sergey Vlasov <vsu@altlinux.ru>

[PATCH] Remove isofs useless unsigned " < 0" comparison

This patch fix gcc-3.4 warnings by remove useless "if (ivalue < 0)"
comparison.

[PATCH] update lm_sensors mailing list address

The lm_sensors project changed mailing lists.

Signed-off-by: Jean Delvare <khali@linux-fr.org>

[PATCH] isofs driver ignore parameters

It seems that Alexander Pytlev's original (simple) patch was correct.

Without it the logic looks a bit like this.

while (...) {
if iocharset
...
else if map
...
if session
...
if sbsector
...
else if check
...
...
else
return 1;
}

Now, if iocharset, map or session are matched, then none of the if or
else if clauses under sbsector will match (that is none of these clauses
match iocharset, map or session), and thus the else clause will be hit,
and the function will return 1 without parsing any furhter options.

With Alexander's fix, the if session and if sbsector clauses
become else if, and its easy to see that the return 1 won't
be premeturely called.

I have tested that this patch works using the testcase options
iocharset=koi8-r,gid=100, and checking that gid is set correctly
with the patch, and incorrectly without.

Here is the patch and signoff again, just for the record.
I will send a second patch to clean up the *value = 0 code
that Marcelo cast concerns over - its bogus but harmless.

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

Change VERSION to v2.4.32-pre3

[PATCH] fix potential NULL dereferences in several serial driver methods (Julien Tinnes)

These patches from Julien Tinnes fix *potential* NULL dereferences in several
serial drivers. Although their known callers can't pass NULL, we cannot tell
about unknown callers (non-mainline patches), so it's safer to check.

Change VERSION to v2.4.32-pre2

[PATCH] PATCH: Fix outstanding gzip/zlib security issues

commit 243393c90f2b7cb781fd794e22786e9c8547901a
Add fakey 'deflateBound()' function to the in-kernel zlib routines

It's not the real deflateBound() in newer zlib libraries, partly because
the upcoming usage of it won't have the "stream" available, so we can't
have the same interfaces anyway.

commit fab5a60a29f98f17256a4183e34a414f6db67569
This uses the new deflateBound() thing to sanity-check the input to the
zlib decompressor before we even bother to start reading in the blocks.

Problem noted by Tim Yamin <plasmaroo@gentoo.org>
author Linus Torvalds <torvalds@g5.osdl.org>

[PATCH] fix oops when starting md multipath 2.4 kernel

The device major/minor numbers no longer match up values recorded in the
descriptor array in the md superblock. Because of the exception made in
the current code, the descriptor entries are removed and although the
real devices are present and accounted for, they are kicked out from
the array. This leaves the array with zero devices. When multipath_run()
is invoked, it blows up expecting to have had some disks.

Lars Marowsky-Bree suggested some patches for md multipath in 2002 but
never made it to mainline 2.4 kernel:

http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D103355467608953&w=3D=2
That patch is large and most of it is not requried for this particular
problem.  The section that reinitializes the descriptor array from
current rdevs for the case of multipath will resolve this issue of
device names shift.

[PATCH] Fix Alpha AXP Cabriolet build

This humble acolyte runs a couple of ancient Alpha AXP 21064 boxes (using
Debian Sarge), and recently when upgrading the kernel from 2.4.18 to
2.4.31 (compiling vanilla sources off of www.kernel.org) I found that the
build would fail when linking the kernel binary. The error was an
unresolved reference to:

     ns87312_enable_ide()

The Alpha variant used was "Cabriolet." The Cabriolet's are rather old,
circa 1995 or '96, motherboards based around the 21064, so I doubt that
there are many of them still running, but I like mine just the same ;-)

Anyhow, a simple one line fix to the arch/alpha/kernel/Makefile solves
this problem (patch file is attached). I've also attached the config file
I used for the build, as well as the boot messages from the kernel built
after the patch was applied.

[PATCH] fix RedBlackTree rb_next/rb_prev functions

I have found a bug in the source of rbtree.c file in /lib. In Kernel 2.6 it's
ok, but 2.4.31 has this error.

We try to use it with the jffs2 source code and only with this fix it work's
fine.

Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>

[PATCH] Revert USB UHCI changes

On Thu, 28 Jul 2005, Johannes Erdfelt wrote:

> Am I missing something here? We're certainly adding TDs to the schedule, so
> why is this patch setting the QH bit?

This is pretty embarrassing.  I didn't realize that the 2.4 driver uses
TDs to mark interrupt queues.  (2.6 uses QHs, which makes more sense.)
Of course, if I had done better testing the problem would have shown up
right away.

So please accept my apology, the UHCI part of that patch was completely
wrong.  Below is another patch to revert it.  The lesson is clear -- from
now on I'll leave the 2.4 driver alone!

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>

[PATCH] Fix XTEA implementation

The XTEA implementation was incorrect due to a misinterpretation of
operator precedence.  Because of the wide-spread nature of this
error, the erroneous implementation will be kept, albeit under the
new name of XETA.

Signed-off-by: Aaron Grothe <ajgrothe@yahoo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[PATCH] Remove bogus declaration of ipt_mutex

Fix compiler error (gcc-4.0) for bogus declaration of ipt_mutex

Signed-off-by: Harald Welte <laforge@netfilter.org>
diff -Nru linux-2.4.31/include/linux/netfilter_ipv4/ip_tables.h linux-2.4.32-pre2/include/linux/netfilter_ipv4/ip_tables.h

[PATCH] Fix incorrect Asus k7m irq router detection

Here is 2.4 version of a patch submitted earlier for 2.6 by Giancarlo
Formicuccia.

this patch:
http://marc.theaimsgroup.com/?l=bk-commits-head&m=111955644929114&w=2
uncovered a k7m bios bug, where the VT82C686A router is reported as
being "586-compatible". The two chips have different pirq mapping, so
this leads to "irq routing conflict" on many pci devices.

Patch for 2.4.32-pre2

Signed-off-by: Aleksey Gorelov <aleksey_gorelov@phoenix.com>
diff --git a/arch/i386/kernel/pci-irq.c b/arch/i386/kernel/pci-irq.c