Linux Kernel Documents

Fork

• linux-2.6
• linux-2.4.36

[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 http://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