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>
[PATCH] usbserial: using int for CPU flags is incorrect on x86_64

Using int for CPU flags is incorrect on x86_64.
[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] 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>
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.
[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>
[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] 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] 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] 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] 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] 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] 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
[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] 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>
Fix printk length modifier of NFS mmap consistency patch
[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] 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] 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] 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