commit 9be78f865844edc728ac933f7161b01e48e1b418
Author: Chris Wright <chrisw@osdl.org>
Date: Fri Sep 16 18:02:12 2005 -0700
Linux 2.6.13.2
commit 59a79e934f84fe9c0fef0c783fba58e9b5b36519
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Mon Sep 12 12:23:25 2005 +0100
[PATCH] USB: ftdi_sio: custom baud rate fix
ftdi_sio: I messed up the baud_base for custom baud rate support in
2.6.13. The attached one-liner patch fixes it.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit d6d47af4c90009c465c7a465dd201a7115af456a
Author: Linus Torvalds <torvalds@osdl.org>
Date: Tue Sep 13 08:01:49 2005 -0700
[PATCH] Fix up more strange byte writes to the PCI_ROM_ADDRESS config word
It's a dword thing, and the value we write is a dword. Doing a byte
write to it is nonsensical, and writes only the low byte, which only
contains the enable bit. So we enable a nonsensical address (usually
zero), which causes the controller no end of problems.
Trivial fix, but nasty to find.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 9c053068c7b8158850d680d8c96f3f11f5804367
Author: Andi Kleen <ak@suse.de>
Date: Tue Sep 13 14:01:08 2005 +0200
[PATCH] Fix MPOL_F_VERIFY
There was a pretty bad bug in there that the code would
always check the full VMA, not the range the user requested.
When the VMA to be checked was merged with the previous VMA this
could lead to spurious failures.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 81ddd439761f2f2e6837f9746c83864f410a4077
Author: Dave Kleikamp <shaggy@austin.ibm.com>
Date: Tue Sep 13 04:16:09 2005 -0400
[PATCH] jfs: jfs_delete_inode must call clear_inode
JFS: jfs_delete_inode should always call clear_inode.
> From Chuck Ebbert:
I'm submitting this patch for -stable:
- it reportedly fixes an oops
- it's already in 2.6.13-git
Signed-off-by: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 504b891bc7cc7fb76e3000b5fe91ca491eb773c5
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Sep 13 09:37:22 2005 +0200
[PATCH] Fix DHCP + MASQUERADE problem
In 2.6.13-rcX the MASQUERADE target was changed not to exclude local
packets for better source address consistency. This breaks DHCP clients
using UDP sockets when the DHCP requests are caught by a MASQUERADE rule
because the MASQUERADE target drops packets when no address is configured
on the outgoing interface. This patch makes it ignore packets with a
source address of 0.
Thanks to Rusty for this suggestion.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 6829c71237ca54f1b752520ba06eacdae68249dc
Author: Willy Tarreau <willy@w.ods.org>
Date: Sun Sep 11 14:10:02 2005 -0700
[PATCH] Sun HME: enable and map PCI ROM properly
This ports the Sun GEM ROM mapping/enable fixes it sunhme (which used
the same PCI ROM mapping code).
Without this, I get NULL MAC addresses for all 4 ports (it's a SUN QFE).
With it, I get the correct addresses (the ones printed on the label on
the card).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 0098d9c5f87aaff2efdcb43e30642dad7ce55b19
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Sun Sep 11 14:08:59 2005 -0700
[PATCH] Sun GEM ethernet: enable and map PCI ROM properly
This same patch was reported to fix the MAC address detection on sunhme
(next patch). Most people seem to be running this on Sparcs or PPC
machines, where we get the MAC address from their respective firmware
rather than from the (previously broken) ROM mapping routines.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit edf3b5b336f55b8a97142592bf5c1b7944deb9d1
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Sun Sep 11 14:07:43 2005 -0700
[PATCH] hpt366: write the full 4 bytes of ROM address, not just low 1 byte
This is one heck of a confused driver. It uses a byte write to a dword
register to enable a ROM resource that it doesn't even seem to be using.
"Lost and wandering in the desert of confusion"
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 2498037d5a6668b733acc712a3106ffd4e1ef735
Author: Manfred Spraul <manfred@colorfullife.com>
Date: Sun Sep 11 21:33:28 2005 +0100
[PATCH] forcedeth: Initialize link settings in every nv_open()
R�diger found a bug in nv_open that explains some of the reports
with duplex mismatches:
nv_open calls nv_update_link_speed for initializing the hardware link speed
registers. If current link setting matches the values in np->linkspeed and
np->duplex, then the function does nothing.
Usually, doing nothing is the right thing, but not in nv_open: During
nv_open, the registers must be initialized because the nic was reset.
The attached patch fixes that by setting np->linkspeed to an invalid value
before calling nv_update_link_speed from nv_open.
Signed-Off-By: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 98debffa9114b60138b3dbd4d02ce13f01a07ab4
Author: Maxim Giryaev <gem@sw.ru>
Date: Fri Sep 9 13:59:48 2005 +0400
[PATCH] Lost sockfd_put() in routing_ioctl()
This patch adds lost sockfd_put() in 32bit compat rounting_ioctl() on
64bit platforms, bug found by Vasiliy Averin <vvs@sw.ru>.
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>
Signed-off-by: Chris Wright <chrisw@osdl.org>
commit 8cd943eb523fa622fec2f8e65e611263babd1249
Author: Maxim Giryaev <gem@sw.ru>
Date: Fri Sep 9 13:05:53 2005 -0700
[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.
(chrisw: Update to use fget_light/fput_light)
Signed-Off-By: Kirill Korotaev <dev@sw.ru>
Signed-Off-By: Maxim Giryaev <gem@sw.ru>
Signed-off-by: Chris Wright <chrisw@osdl.org>
www.fiveanddime.net
