Merge branch 'next'

Change VERSION to 2.4.33

[PATCH] export memchr() which is used by smbfs and lp driver.

Recently, an smbfs fix added a dependency on memchr() which is
not exported if smbfs is built as a module.

Signed-Off-By: Willy Tarreau <w@1wt.eu>

[PKTGEN] : fix an oops when used with bonding driver (Tien ChenLi)

Back-port from Tien ChenLi's 2.6 patch described this below.

"I fixed a bug in pktgen so it won't cause oops when used with
balance-tlb or balance-alb bonding driver".

The root cause is that the bond_alb_xmit in bonding will peek the
destination address in packet via the skb->nh.iph pointer, generally
this will be filled by upper layer network driver, but the packet
generated by pktgen will be sent to device driver so it will need to
set this pointer correctly. The other two pointers are not necessary
for now, they are set to avoid similar problem.

[PATCH] USB: unsigned long flags

After a similar problem surfaced in usbserial, I looked across the code base
and found this instance. The bug is obvious: local_irq_save takes a long,
not int.

Signed-Off-By: Pete Zaitcev <zaitcev@redhat.com>

[PATCH] USB: Little Rework for usbserial

This patch fixes various hangs and oopses which happen if serial devices
are handled roughly (e.g. disconnected while open), open-close-open
races and hangs, and issues with getty running on ttyUSBx.

Finally, I got rid of the "#ifdef I_AM_A_DARING_HACKER". Originally,
I thought it would be there for a week or two, and it was stuck in the
code for two years.

Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>

[PATCH] AVM C4 ISDN card : use cpu_relax() in busy loops

As suggested by Alan, use cpu_relax() in 3 busy loops : "It's a
polled busy loop so you want other CPU threads to run if possible".

Signed-off-by: Willy Tarreau <w@1wt.eu>

[PATCH] Fix AVM C4 ISDN card init problems with newer CPUs

AVM C4 ISDN NIC: Add three memory barriers, taken from 2.6.7,
(they are there in 2.6.17.7 too), to fix module initialization
problems appearing with at least some newer Celerons and
Pentium III.

Signed-off-by: Jukka Partanen <jspartanen@gmail.com>
Acked-by: Karsten Keil <kkeil@suse.de>

[PATCH] Bug with USB proc_bulk in 2.4 kernel

Replace the semaphore exclusive_access with an open-coded lock for
the special use. The lock can be taken for: read, write, and both.
This way, two bulk URBs can be submitted simultaneously with ioctl
USBDEVFS_BULK: one read and one write. Such access was possible
before 2.4.28.

The semaphore was introduced in 2.4.28 for the purpose of exclusion
between access from device.c (cat /proc/bus/usb/devices), devio.c
through libusb, and in-kernel driver. Currently, only usb-storage
observes the locking protocol. The most popular device which locks
in case of simultaneous access is TEAC CD-210PU.

Signed-off-By: Pete Zaitcev <zaitcev@redhat.com>

[PATCH] [BLKMTD] : missing offset sometimes causes panics

Using JFFS2 on CompactFlash devices via blkmtd on kernel 2.4.32 causes
occasionnal kernel panics.

It happens that every few days (5-10 days), we encounter a kernel BUG in
set_bh_page() during a write because ->offset is bigger than PAGE_SIZE.
The call chain passes via jffs2 and blkmtd. I finally tracked it down to
the commit_pages() function in blkmtd not setting the ->offset member
in the kiovec structure. This one only gets initialized on a previous
read, because kiobuf_init() does not set it either.

I found it logical to set it to zero in commit_pages() because this
function also sets the ->length parameter to a page-aligned value.

2.6 does not have this problem, because it does not use kiovecs.

I suspect not many people use jffs2 on top of blkmtd, and even in this
case, the conditions to meet to trigger the bug are not common at all.

Signed-Off-By: Willy Tarreau <w@1wt.eu>
Ack-By: David Woodhouse <dwmw2@infradead.org>

[PATCH] 2.4 NFS client - update d_cache when server reports ENOENT on an NFS remove

Anuwat Phrukphicharn of HP discovered and patched this problem in
RHEL-3, and asked that I push it upstream.

When the 2.4 NFS client does a REMOVE and gets an ENOENT back from the
server it does not remove the dentry from the d_cache. This can make it
inappropriately keep writing to an inode that has been renamed.

To reproduce, run this on an NFS server with /scratch exported:

#!/bin/sh
dir=/scratch/98201
mkdir -p $dir/recv
cat /dev/null > $dir/recv/x
while true; do
        length=`wc -l $dir/recv/x | cut -d' ' -f1`
        if [ ${length} -gt 1 ]; then
                echo "problem occured!"
                date
                exit 1
        fi
        mv $dir/x $dir/recv/x
        sleep 1
done

...and then do this on the client:

mount server:/scratch /mnt/server
while true; do
        rm -f /mnt/server/98201/x
        date >> /mnt/server/98201/x
        usleep 100
done

The file "x" should never contain more than 1 line, but occasionally,
the server will report an ENOENT back to the client (indicating that the
server script has renamed the file before the rm could occur). After
this, the client will keep appending to the same inode, even though the
file has been renamed.

I've not seen this problem in 2.6 kernels, but I've not done any
extensive testing there as of yet so I can't confirm whether it's still
a problem there or not.

A patch to fix this follows. It just makes ENOENT a special case when
handling errors in the nfs_safe_remove function, and lets the client
update the dcache as if the remove had succeeded. The ENOENT is still
reported back to userspace. This corrected the problem on my test rig
and for the reporter as well:

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

Change VERSION to 2.4.33-rc3

[PATCH-2.4] Typo in cdrom.c

Discussion here :
  http://bugzilla.kernel.org/show_bug.cgi?id=2966

The typo seems to exist in linux-2.4 too, at least in
2.4.32, 2.4.32-hf32.6 and 2.4.33pre3. The fix for
linux-2.4 would be just like the proposed patch for
linux-2.6.

[PATCH] ethtool: two oopses in ethtool_set_coalesce() and ethtool_set_pauseparam()

The function pointers which were checked were for their get_* counterparts.
Typically a copy-paste typo.

Signed-off-by: Willy Tarreau <w@1wt.eu>

[PATCH] EXT3: ext3 block bitmap leakage

This patch fixes ext3 block bitmap leakage,
which leads to the following fsck messages on
_healthy_ filesystem:
Block bitmap differences:  -64159 -73707

All kernels up to 2.6.17 have this bug.

Found by
   Vasily Averin <vvs@sw.ru> and Andrey Savochkin <saw@sawoct.com>
Test case triggered the issue was created by
   Dmitry Monakhov <dmonakhov@sw.ru>

Signed-Off-By: Vasiliy Averin <vvs@sw.ru>
Signed-Off-By: Andrey Savochkin <saw@sawoct.com>
Signed-Off-By: Kirill Korotaev <dev@openvz.org>
CC: Dmitry Monakhov <dmonakhov@sw.ru>

[PATCH] range checking for sleep states sent to /proc/acpi/sleep

A range checking is missing in acpi_system_write_sleep() in kernel
2.4, and writing a large integer value to /proc/acpi/sleep will cause
an oops. I could reproduce one this way :

   # echo 0x800000 >/proc/acpi/sleep

Fix extracted from the PaX patch.

Change VERSION to v2.4.33-rc2

[PATCH] Fix vfs_unlink/NFS NULL pointer dereference

v2.4.33-pre introduced a fix for lack of synchronization between
link/unlink which requires vfs_unlink to grab i_zombie of both the
victim and its parent with double_down().

Problem is that NFS client deletes the victim dentry on ->unlink,
resulting in a NULL dereference when vfs_unlink() tries to up
dentry->d_inode->i_zombie.

Keep a copy of the inode pointer, incrementing its reference counter, to
fix the situation.

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

[NETFILTER]: Fix do_add_counters race, possible oops or info leak (CVE-2006-0039)

Solar Designer found a race condition in do_add_counters(). The beginning
of paddc is supposed to be the same as tmp which was sanity-checked
above, but it might not be the same in reality. In case the integer
overflow and/or the race condition are triggered, paddc->num_counters
might not match the allocation size for paddc. If the check below
(t->private->number != paddc->num_counters) nevertheless passes (perhaps
this requires the race condition to be triggered), IPT_ENTRY_ITERATE()
would read kernel memory beyond the allocation size, potentially causing
an oops or leaking sensitive data (e.g., passwords from host system or
from another VPS) via counter increments. This requires CAP_NET_ADMIN.

Signed-off-by: Solar Designer <solar@openwall.com>
Signed-off-by: Kirill Korotaev <dev@openvz.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SCTP]: Respect the real chunk length when walking parameters. (CVE-2006-1858)

When performing bound checks during the parameter processing, we
want to use the real chunk and paramter lengths for bounds instead
of the rounded ones.  This prevents us from potentially walking of
the end if the chunk length was miscalculated.  We still use rounded
lengths when advancing the pointer. This was found during a
conformance test that changed the chunk length without modifying
parameters.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SCTP]: Validate the parameter length in HB-ACK chunk. (CVE-2006-1857)

If SCTP receives a badly formatted HB-ACK chunk, it is possible
that we may access invalid memory and potentially have a buffer
overflow.  We should really make sure that the chunk format is
what we expect, before attempting to touch the data.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PATCH 2.4.33-rc1] repair __ide_dma_no_op breakage

> Willy TARREAU:
>      ide: trying to enable DMA may cause an oops

This patch to ide-dma.c defines a function 'int __ide_dma_no_op(void)'
and stores its address in function pointer fields with type
'int (*)(ide_drive_t*)'. Thus callers will call __ide_dma_no_op() with
more parameters than it expects.

This is invalid C and it will break horribly in some valid calling
conventions (in particular, when parameters are passed on the stack
and the callee not the caller pops them).

Furtunately the fix is simple: just define __ide_dma_no_op() with
the correct prototype (taking an unused ide_drive_t* parameter),
and drop the now redundant casts from the assignments. Also make
__ide_dma_no_op() 'static' as it is local to ide-dma.c.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>

Update VERSION to v2.4.33-rc1

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

[PATCH] forcedeth update to 0.50

While testing the forcedeth driver on a SunFire X2100 (Opteron Dual
Core), I encountered problems with the driver hanging after a few
megabytes while pushing traffic at Gbps speed. The driver was at 0.30.
An mostly trivial update to 0.50 fixed all the problems and brought a
huge performance boost. However, max_interrupt_work should be set to
10 not 5 above 400 kpps.

[PATCH] i2c: Delete 2 out-of-date, colliding ioctl defines

Delete 2 out-of-date, colliding ioctl defines

I2C_UDELAY and I2C_MDELAY are supposed to be used by i2c-algo-bit, but
actually aren't (and I suspect never were). That wouldn't be a major
issue, but it happens that their values are the same as I2C_FUNCS and
I2C_SLAVE_FORCE, respectively, which *are* widely used. It might cause
unnecessary confusion, thus I think it's better to get rid of them,
as was already done in Linux 2.6 and i2c-CVS 7 months ago.

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=80ce3b7d0f52877b80cddc3ace8b332d888f0131

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

[PATCH] scx200_acb: Fix resource name use after free

scx200_acb: Fix resource name use after free

We can't pass a string on the stack to request_region. As soon as we
leave the function that stack is gone and the string is lost. Let's
use the same string we identify the i2c_adapter with instead, it's
more simple, more consistent, and just works.

This is the second half of fix to bug #6445.

It was merged in 2.6.17-rc4:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b33d0798e6cfae1fcee75afc808fe5690a48a814

And 2.6.16.17:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=commit;h=9a4a3539b356a8f4da8c6ace95bc4135314fed7e

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

[NETFILTER]: Fix possible overflow in netfilters do_replace()

netfilter's do_replace() can overflow on addition within SMP_ALIGN()
and/or on multiplication by NR_CPUS, resulting in a buffer overflow on
the copy_from_user().  In practice, the overflow on addition is
triggerable on all systems, whereas the multiplication one might require
much physical memory to be present due to the check above.  Either is
sufficient to overwrite arbitrary amounts of kernel memory.

I really hate adding the same check to all 4 versions of do_replace(),
but the code is duplicate...

Found by Solar Designer during security audit of OpenVZ.org

Signed-Off-By: Kirill Korotaev <dev@openvz.org>
Signed-Off-By: Solar Designer <solar@openwall.com>
Signed-off-by: Patrck McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SCTP]: Fix panic's when receiving fragmented SCTP control chunks. (CVE-2006-2272)

Use pskb_pull() to handle incoming COOKIE_ECHO and HEARTBEAT chunks that
are received as skb's with fragment list.

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

[SCTP]: Prevent possible infinite recursion with multiple bundled DATA. (CVE-2006-2274)

There is a rare situation that causes lksctp to go into infinite recursion
and crash the system.  The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself.  This causes
sctp_skb_pull() to potentially recurse indefinitely.

Proposed solution is to make a copy of the skb when attempting to link
things using frag_list.

Signed-off-by: Vladislav Yasevich <vladsilav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[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] USB: Gadget RNDIS fix alloc bug. (buffer overflow)

Remote NDIS response to OID_GEN_SUPPORTED_LIST only allocated space
for the data attached to the reply, and not the reply structure
itself. This caused other kmalloc'd memory to be corrupted.

Signed-off-by: Shaun Tancheff <shaun@tancheff.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[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.