Linux kernel changesets from commits (Linux 2.4 version)

Linux Kernel Mailing List | 12 Apr 2006 21:59

[PATCH] Always check that RIPs are canonical during signal handling

commit e5a190da220758a739a31189440669c37fcd9773
tree 5ce75f4f0a50a2dba708533cb2b855f20cc2894d
parent 09d3b3dcfa80c9094f1748c1be064b9326c9ef2b
author Andi Kleen <ak <at> suse.de> Tue, 11 Apr 2006 12:34:45 +0200
committer Marcelo Tosatti <marcelo <at> dmt.cnet> Thu, 13 Apr 2006 01:16:58 -0500

[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 <at> redhat.com

Signed-off-by: Andi Kleen <ak <at> suse.de>

 arch/x86_64/kernel/signal.c |   19 +++++++++++++------
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/x86_64/kernel/signal.c b/arch/x86_64/kernel/signal.c

(Continue reading)

headers

Linux Kernel Mailing List | 19 Apr 2006 23:59

[PATCH] x86-64: Always check that RIPs are canonical during signal handling (update)

commit 7e52c418ae80c7a00d97e9a6a1c6b2c9e7184018
tree 5ddde7d5fdf3aaeb6f048dfb69e7fd99d082b1d5
parent e5a190da220758a739a31189440669c37fcd9773
author Andi Kleen <ak <at> suse.de> Tue, 18 Apr 2006 12:21:25 +0200
committer Marcelo Tosatti <marcelo <at> dmt.cnet> Thu, 20 Apr 2006 03:58:31 -0500

[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 <at> redhat.com

Signed-off-by: Andi Kleen <ak <at> suse.de>

(Continue reading)

headers

Linux Kernel Mailing List | 19 Apr 2006 23:59

[PATCH] quota_v2 module taints the kernel (missing licence)

commit e2577e4a7fcb8905953295c4a53836bbec42a190
tree 401f10a1f94a01c8c71fbf5064f4b1eeb22ad538
parent 6b56c2053649d588df0ab750f404ccd39664f87f
author Marek Szuba <cyberman <at> if.pw.edu.pl> Fri, 23 Dec 2005 17:29:44 +0100
committer Willy TARREAU <willy <at> pcw.(none)> Sat, 15 Apr 2006 12:26:34 +0200

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

 fs/quota_v2.c |    4 ++++
 1 files changed, 4 insertions(+)

diff --git a/fs/quota_v2.c b/fs/quota_v2.c
index 87ffeca..572f70d 100644
--- a/fs/quota_v2.c
+++ b/fs/quota_v2.c
 <at>  <at>  -14,6 +14,10  <at>  <at> 
 #include <asm/byteorder.h>
 #include <asm/uaccess.h>

+MODULE_AUTHOR("Jan Kara");
+MODULE_DESCRIPTION("Quota format v2 support");
+MODULE_LICENSE("GPL");
+
 #define __QUOTA_V2_PARANOIA

(Continue reading)

headers

Linux Kernel Mailing List | 19 Apr 2006 23:59

[PATCH] 2.4 nfs cache consistency problem with mmap'ed files

commit 1b6e03e34074439bce3ef9eb9ca833cf6fff6b5a
tree e17b946de889aa3e8ea1c10b16395468a4cee3dd
parent e5a190da220758a739a31189440669c37fcd9773
author Jeff Layton <jtlayton <at> poochiereds.net> Sat, 08 Apr 2006 15:43:29 -0400
committer Willy TARREAU <willy <at> pcw.(none)> Sat, 15 Apr 2006 11:07:34 +0200

[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

(Continue reading)

headers

Linux Kernel Mailing List | 19 Apr 2006 23:59

[PATCH] VLAN: Add two missing checks to vlan_ioctl_handler()

commit 6b56c2053649d588df0ab750f404ccd39664f87f
tree b68f3c6398a207c6d97132ab5660f2ca39af126d
parent 1b6e03e34074439bce3ef9eb9ca833cf6fff6b5a
author Mika Kukkonen <mikukkon <at> iki.fi> Wed, 21 Dec 2005 22:50:15 +0200
committer Willy TARREAU <willy <at> pcw.(none)> Sat, 15 Apr 2006 12:13:30 +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 <at> iki.fi>

 net/8021q/vlan.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 7498888..3c67e20 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
 <at>  <at>  -757,6 +757,8  <at>  <at>  int vlan_ioctl_handler(unsigned long arg

 	case GET_VLAN_REALDEV_NAME_CMD:
 		err = vlan_dev_get_realdev_name(args.device1, args.u.device2);
+		if (err)
+			goto out;
 		if (copy_to_user((void*)arg, &args,
 				 sizeof(struct vlan_ioctl_args))) {
 			err = -EFAULT;
 <at>  <at>  -765,6 +767,8  <at>  <at>  int vlan_ioctl_handler(unsigned long arg

(Continue reading)

headers

Linux Kernel Mailing List | 19 Apr 2006 23:59

[PATCH] e1000: Fix mii-tool access to setting speed and duplex

commit 19534b446bc1835abbf17d1ff7a3a15481a35567
tree 518f789306e5cecd79c2c87140c3d865565f72e2
parent e2577e4a7fcb8905953295c4a53836bbec42a190
author Willy TARREAU <willy <at> pcw.(none)> Sat, 15 Apr 2006 13:06:33 +0200
committer Willy TARREAU <willy <at> pcw.(none)> Sat, 15 Apr 2006 13:06:33 +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 <at> w.ods.org>

 drivers/net/e1000/e1000_main.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index b9d3177..3342142 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
 <at>  <at>  -2755,7 +2755,7  <at>  <at>  e1000_mii_ioctl(struct net_device *netde
 		if (e1000_write_phy_reg(&adapter->hw, data->reg_num,
 					mii_reg))
 			return -EIO;
-		if (adapter->hw.phy_type == e1000_phy_m88) {
+		if (adapter->hw.media_type == e1000_media_type_copper) {
 			switch (data->reg_num) {

(Continue reading)

headers

Linux Kernel Mailing List | 27 Apr 2006 01:59

[PATCH] fix shm mprotect (CVE-2006-1524)

commit 0dba0f6b382bf360a1974fd78538273478dfc784
tree 99fca29bf28dcd04c93b43b7575aaa00f5794288
parent 3c1e09e173e5fec7535a3795c4bc7870c8026ff3
author Hugh Dickins <hugh <at> veritas.com> Tue, 25 Apr 2006 20:05:59 +0100
committer Marcelo Tosatti <marcelo <at> dmt.cnet> Thu, 27 Apr 2006 02:48:15 -0300

[PATCH] fix shm mprotect (CVE-2006-1524)

shmat stop mprotect from giving write permission to a readonly attachment.

Signed-off-by: Hugh Dickins <hugh <at> veritas.com>

 ipc/shm.c |    2 ++
 1 files changed, 2 insertions(+)

diff --git a/ipc/shm.c b/ipc/shm.c
index 1df0577..36cb09a 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
 <at>  <at>  -161,6 +161,8  <at>  <at>  static int shm_mmap(struct file * file, 
 {
 	UPDATE_ATIME(file->f_dentry->d_inode);
 	vma->vm_ops = &shm_vm_ops;
+	if (!(vma->vm_flags & VM_WRITE))
+		vma->vm_flags &= ~VM_MAYWRITE;
 	shm_inc(file->f_dentry->d_inode->i_ino);
 	return 0;
 }

headers

Linux Kernel Mailing List | 27 Apr 2006 01:59

[PATCH] i386/x86-64: Fix x87 information leak between processes

commit d296e6191afbfc63077da02a1386bcd73bd4c1e0
tree 9c6968091a4104fb8c9fd2abb6af043fefbba746
parent 0dba0f6b382bf360a1974fd78538273478dfc784
author Andi Kleen <ak <at> suse.de> Wed, 19 Apr 2006 10:22:07 +0200
committer Marcelo Tosatti <marcelo <at> dmt.cnet> Thu, 27 Apr 2006 02:48:18 -0300

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

(Continue reading)

headers

Linux Kernel Mailing List | 1 May 2006 09:59

Fix printk length modifier of NFS mmap consistency patch

commit 25c32b0159f356cb468f39dfeb60e08dd01e8d9f
tree 37d80930edb0d5cfdc11da33777b4b71ac950c07
parent 55d98d40c8ef4324eb6fad08c09e8c0a20aa5c3c
author Marcelo Tosatti <marcelo <at> dmt.cnet> Mon, 01 May 2006 08:57:54 -0300
committer Marcelo Tosatti <marcelo <at> dmt.cnet> Mon, 01 May 2006 08:57:54 -0300

Fix printk length modifier of NFS mmap consistency patch

 fs/nfs/inode.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index d5ab299..48afccb 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
 <at>  <at>  -1101,7 +1101,7  <at>  <at>  __nfs_refresh_inode(struct inode *inode,
 		invalidate_inode_pages(inode);
 		if (! list_empty(&inode->i_mapping->clean_pages)) {
 			dfprintk(PAGECACHE,
-				 "NFS: clean_pages for %x/%d is not empty\n",
+				 "NFS: clean_pages for %x/%ld is not empty\n",
 				 inode->i_dev, inode->i_ino);
 			NFS_FLAGS(inode) |= NFS_INO_MAPPED;
 		}

headers

Linux Kernel Mailing List | 1 May 2006 09:59

[PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards

commit 8828db2ed1908d2a19d61a5d9a63719bb0083d22
tree 9a5434514577287ae691900c0f7dddb47f9d82e2
parent d296e6191afbfc63077da02a1386bcd73bd4c1e0
author Craig Brind <craigbrind <at> gmail.com> Mon, 24 Apr 2006 23:35:41 +0200
committer Marcelo Tosatti <marcelo <at> dmt.cnet> Sun, 30 Apr 2006 20:37:05 -0300

[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 <at> gmail.com>
Signed-off-by: Roger Luethi <rl <at> hellgate.ch>

(Continue reading)

1	August 2006
4	July 2006
16	June 2006
25	May 2006
8	April 2006
2	March 2006
8	July 2005
34	June 2005
54	May 2005
24	April 2005
107	March 2005
126	February 2005
136	January 2005
125	December 2004
151	November 2004
145	October 2004
127	September 2004
291	August 2004
116	July 2004
240	June 2004
293	May 2004
273	April 2004
335	March 2004
279	February 2004
319	January 2004
578	December 2003
358	November 2003
495	October 2003
495	September 2003
466	August 2003
563	July 2003
517	June 2003
357	May 2003
314	April 2003
414	March 2003
387	February 2003
359	January 2003
439	December 2002
193	November 2002
319	October 2002
57	September 2002
22	August 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30