OSDN Git Service
Willy Tarreau [Tue, 30 May 2006 22:03:19 +0000 (00:03 +0200)]
[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.
Jean Delvare [Wed, 31 May 2006 16:28:48 +0000 (18:28 +0200)]
[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>
Jean Delvare [Wed, 31 May 2006 15:16:16 +0000 (17:16 +0200)]
[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>
Shaun Tancheff [Wed, 22 Feb 2006 23:47:34 +0000 (19:47 -0400)]
[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>
Marcelo Tosatti [Fri, 26 May 2006 19:41:06 +0000 (16:41 -0300)]
[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>
Willy TARREAU [Sun, 21 May 2006 23:08:34 +0000 (19:08 -0400)]
[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.
Theodore Ts'o [Sun, 21 May 2006 23:08:34 +0000 (19:08 -0400)]
[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>
Patrick McHardy [Tue, 23 May 2006 08:05:41 +0000 (01:05 -0700)]
[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>
Sergei Shtylyov [Sat, 8 Apr 2006 06:50:39 +0000 (10:50 +0400)]
[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>
Marcelo Tosatti [Fri, 12 May 2006 18:02:33 +0000 (15:02 -0300)]
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.
Willy TARREAU [Sun, 7 May 2006 21:54:44 +0000 (23:54 +0200)]
Merge branch 'updates'
Willy TARREAU [Sun, 7 May 2006 21:48:50 +0000 (23:48 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 21:42:20 +0000 (23:42 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 21:38:01 +0000 (23:38 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 21:33:09 +0000 (23:33 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 21:19:26 +0000 (23:19 +0200)]
[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
Jesper Juhl [Sun, 7 May 2006 02:26:10 +0000 (04:26 +0200)]
[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>
Willy TARREAU [Sun, 7 May 2006 19:53:31 +0000 (21:53 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 19:44:36 +0000 (21:44 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 19:35:47 +0000 (21:35 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 19:33:23 +0000 (21:33 +0200)]
[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
Pradeep Vincent [Mon, 28 Nov 2005 11:57:00 +0000 (12:57 +0100)]
[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
Olaf Kirch [Fri, 5 May 2006 01:40:41 +0000 (18:40 -0700)]
[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>
Willy TARREAU [Thu, 20 Apr 2006 09:08:08 +0000 (11:08 +0200)]
[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
Willy TARREAU [Sun, 7 May 2006 07:23:35 +0000 (09:23 +0200)]
Merge branch 'origin'
Marcelo Tosatti [Thu, 4 May 2006 22:54:22 +0000 (19:54 -0300)]
Contact information update
Marcelo Tosatti [Mon, 1 May 2006 05:57:54 +0000 (02:57 -0300)]
Fix printk length modifier of NFS mmap consistency patch
Marcelo Tosatti [Sun, 30 Apr 2006 17:41:33 +0000 (14:41 -0300)]
Change VERSION to v2.4.33-pre3
Craig Brind [Mon, 24 Apr 2006 21:35:41 +0000 (23:35 +0200)]
[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>
Andi Kleen [Wed, 19 Apr 2006 08:22:07 +0000 (10:22 +0200)]
[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>
Hugh Dickins [Tue, 25 Apr 2006 19:05:59 +0000 (20:05 +0100)]
[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>
Willy TARREAU [Thu, 20 Apr 2006 09:08:08 +0000 (11:08 +0200)]
[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
Marcelo Tosatti [Wed, 19 Apr 2006 23:00:11 +0000 (18:00 -0500)]
Merge w.ods.org/kernel/2.4/linux-2.4-upstream
Andi Kleen [Tue, 18 Apr 2006 10:21:25 +0000 (12:21 +0200)]
[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>
Willy TARREAU [Sat, 15 Apr 2006 11:06:33 +0000 (13:06 +0200)]
[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>
Marek Szuba [Fri, 23 Dec 2005 16:29:44 +0000 (17:29 +0100)]
[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.
Mika Kukkonen [Wed, 21 Dec 2005 20:50:15 +0000 (22:50 +0200)]
[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>
Jeff Layton [Sat, 8 Apr 2006 11:43:29 +0000 (07:43 -0400)]
[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>
Andi Kleen [Tue, 11 Apr 2006 10:34:45 +0000 (12:34 +0200)]
[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>
Pavel Kankovsky [Sat, 4 Mar 2006 13:53:16 +0000 (14:53 +0100)]
[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.
Marin Mitov [Sun, 5 Mar 2006 16:30:23 +0000 (18:30 +0200)]
[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.
Stefan-W. Hahn [Fri, 3 Mar 2006 18:01:01 +0000 (19:01 +0100)]
[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>
Jesse Brandeburg [Fri, 24 Feb 2006 23:42:30 +0000 (15:42 -0800)]
[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>
David S. Miller [Tue, 7 Mar 2006 23:00:30 +0000 (15:00 -0800)]
[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>
Andi Kleen [Wed, 1 Mar 2006 13:39:51 +0000 (14:39 +0100)]
[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>
Stephen Rothwell [Mon, 27 Feb 2006 05:03:37 +0000 (16:03 +1100)]
[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>
Marcelo Tosatti [Tue, 21 Feb 2006 00:39:28 +0000 (18:39 -0600)]
Change VERSION to 2.4.33-pre2
Jesse Brandeburg [Thu, 16 Feb 2006 21:49:12 +0000 (13:49 -0800)]
[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
Rik van Riel [Fri, 17 Feb 2006 21:03:32 +0000 (16:03 -0500)]
[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>
Marcelo Tosatti [Fri, 17 Feb 2006 19:38:45 +0000 (13:38 -0600)]
Merge w.ods.org/kernel/2.4/linux-2.4-upstream
Horms [Wed, 8 Feb 2006 09:35:27 +0000 (18:35 +0900)]
[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
Willy Tarreau [Wed, 1 Feb 2006 05:16:30 +0000 (06:16 +0100)]
Merge branch 'master' of /data/projets/git/linux/linux-2.4
Jacek Lipkowski [Tue, 31 Jan 2006 22:29:05 +0000 (23:29 +0100)]
[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
Marcelo Tosatti [Tue, 31 Jan 2006 22:26:40 +0000 (16:26 -0600)]
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.
David S. Miller [Tue, 31 Jan 2006 00:44:42 +0000 (16:44 -0800)]
[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>
Willy Tarreau [Fri, 27 Jan 2006 17:36:25 +0000 (18:36 +0100)]
Merge branch 'master' of /data/projets/git/linux/linux-2.4
Guennadi Liakhovetski [Fri, 20 Jan 2006 08:33:26 +0000 (09:33 +0100)]
[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>
dann frazier [Tue, 17 Jan 2006 03:47:26 +0000 (20:47 -0700)]
[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>
Adrian Bunk [Fri, 6 Jan 2006 20:37:27 +0000 (21:37 +0100)]
[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>
Pete Zaitcev [Fri, 6 Jan 2006 23:21:23 +0000 (15:21 -0800)]
[PATCH] usbserial: using int for CPU flags is incorrect on x86_64
Using int for CPU flags is incorrect on x86_64.
ODonnell, Michael [Fri, 6 Jan 2006 18:49:10 +0000 (13:49 -0500)]
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>
Vincent Fortier [Thu, 5 Jan 2006 23:11:25 +0000 (00:11 +0100)]
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.
Steven J. Hathaway [Thu, 5 Jan 2006 22:55:26 +0000 (23:55 +0100)]
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).
Horms [Thu, 5 Jan 2006 08:29:02 +0000 (17:29 +0900)]
[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>
Marcelo Tosatti [Wed, 28 Dec 2005 20:15:56 +0000 (18:15 -0200)]
Merge /pub/scm/linux/kernel/git/davem/net-2.4
David S. Miller [Tue, 27 Dec 2005 00:58:20 +0000 (16:58 -0800)]
[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>
David Stevens [Tue, 27 Dec 2005 00:37:17 +0000 (16:37 -0800)]
[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>
Marcelo Tosatti [Sat, 24 Dec 2005 14:39:02 +0000 (12:39 -0200)]
Change VERSION to 2.4.33-pre1
Maciej W. Rozycki [Sun, 18 Dec 2005 20:06:59 +0000 (21:06 +0100)]
[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>
Marcelo Tosatti [Fri, 23 Dec 2005 21:13:05 +0000 (19:13 -0200)]
Merge w.ods.org/kernel/2.4/linux-2.4-upstream
Dave Anderson [Fri, 25 Nov 2005 03:00:35 +0000 (12:00 +0900)]
[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.
Pete Zaitcev [Fri, 23 Dec 2005 01:20:22 +0000 (17:20 -0800)]
[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
David S. Miller [Wed, 21 Dec 2005 21:39:23 +0000 (13:39 -0800)]
[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>
David S. Miller [Fri, 26 Aug 2005 22:19:11 +0000 (15:19 -0700)]
[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>
David S. Miller [Fri, 26 Aug 2005 21:49:00 +0000 (14:49 -0700)]
[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>
David S. Miller [Fri, 26 Aug 2005 21:18:06 +0000 (14:18 -0700)]
[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>
Willy Tarreau [Tue, 13 Dec 2005 11:05:00 +0000 (12:05 +0100)]
[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.
Horms [Mon, 19 Dec 2005 10:16:12 +0000 (19:16 +0900)]
[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>
Vijay Sampath [Sun, 18 Dec 2005 18:50:54 +0000 (10:50 -0800)]
[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>
NeilBrown [Tue, 29 Nov 2005 12:04:13 +0000 (13:04 +0100)]
[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>
Marcus Meissner [Tue, 29 Nov 2005 10:59:07 +0000 (11:59 +0100)]
[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
Akira Tsukamoto [Mon, 5 Dec 2005 02:30:29 +0000 (11:30 +0900)]
[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>
Vasily Averin [Sun, 27 Nov 2005 17:15:06 +0000 (20:15 +0300)]
[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>
Yan Zheng [Tue, 29 Nov 2005 10:40:10 +0000 (11:40 +0100)]
[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
Linus Torvalds [Tue, 29 Nov 2005 10:38:30 +0000 (11:38 +0100)]
[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>
Willy Tarreau [Wed, 2 Nov 2005 21:31:09 +0000 (22:31 +0100)]
[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>
Jeff Garzik [Thu, 1 Dec 2005 21:40:40 +0000 (16:40 -0500)]
[libata] fix potential oops in pdev_printk() compat helper
Jeff Garzik [Wed, 30 Nov 2005 21:24:50 +0000 (16:24 -0500)]
[libata] fix build
Jeff Garzik [Wed, 30 Nov 2005 21:19:23 +0000 (16:19 -0500)]
[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
Jeff Garzik [Wed, 30 Nov 2005 18:39:59 +0000 (13:39 -0500)]
[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
Jeff Garzik [Wed, 30 Nov 2005 17:33:22 +0000 (12:33 -0500)]
[libata sata_sx4] trim trailing whitespace
Preparation for resync with 2.6.14.
Jeff Garzik [Wed, 30 Nov 2005 16:23:46 +0000 (11:23 -0500)]
[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
Akira Tsukamoto [Thu, 24 Nov 2005 18:00:05 +0000 (03:00 +0900)]
[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>
Adrian Bunk [Sat, 26 Nov 2005 23:36:37 +0000 (00:36 +0100)]
[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(-)
Krzysztof Strasburger [Wed, 2 Nov 2005 09:43:36 +0000 (10:43 +0100)]
[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
Chris Ross [Wed, 23 Nov 2005 15:56:00 +0000 (15:56 +0000)]
[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.
dann frazier [Fri, 18 Nov 2005 22:42:19 +0000 (15:42 -0700)]
[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>
Nick Warne [Mon, 28 Nov 2005 05:49:58 +0000 (06:49 +0100)]
[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>
Adrian Bunk [Tue, 8 Nov 2005 02:02:12 +0000 (03:02 +0100)]
[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>
Vasily Averin [Sat, 26 Nov 2005 09:23:59 +0000 (12:23 +0300)]
[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>