[kernel] r6747 -
dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches
Dann Frazier
dannf at costa.debian.org
Mon May 29 02:47:57 UTC 2006
Author: dannf
Date: Mon May 29 02:47:50 2006
New Revision: 6747
Modified:
dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/213_madvise_remove-restrict.diff
Log:
switch to upstream 2.4 changeset
Modified: dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/213_madvise_remove-restrict.diff
==============================================================================
--- dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/213_madvise_remove-restrict.diff (original)
+++ dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/213_madvise_remove-restrict.diff Mon May 29 02:47:50 2006
@@ -1,54 +1,21 @@
-Trivial backport of the origional pattch. This patch will apply to both Sarge
-2.4.27 and 2.6.8.
+From: Hugh Dickins <hugh at veritas.com>
+Date: Tue, 25 Apr 2006 19:05:59 +0000 (+0100)
+Subject: [PATCH] fix shm mprotect (CVE-2006-1524)
+X-Git-Tag: v2.4.33-pre3
+X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commitdiff;h=0dba0f6b382bf360a1974fd78538273478dfc784
-Signed-off-by: Troy Heber <troyh at debian.org>
+[PATCH] fix shm mprotect (CVE-2006-1524)
-diff-tree 512dba41bae0ec8de72269167f23b75a4770097d (from 23e0ac040b8052729c32dfec78f751d82515e73e)
-Author: Hugh Dickins <hugh at veritas.com>
-Date: Wed Apr 12 14:34:27 2006 -0700
+shmat stop mprotect from giving write permission to a readonly attachment.
- [PATCH] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524)
-
- I found that all of 2.4 and 2.6 have been letting mprotect give write
- permission to a readonly attachment of shared memory, whether or not IPC
- would give the caller that permission.
-
- SUS says "The behaviour of this function [mprotect] is unspecified if the
- mapping was not established by a call to mmap", but I don't think we can
- interpret that as allowing it to subvert IPC permissions.
-
- I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and
- the patch below reproduces that behaviour - mprotect cannot be used to add
- write permission to a shared memory segment attached readonly.
-
- This patch is simple, and I'm sure it's what we should have done in 2.4.0:
- if you want to go on to switch write permission on and off with mprotect,
- just don't attach the segment readonly in the first place.
-
- However, we could have accumulated apps which attach readonly (even though
- they would be permitted to attach read/write), and which subsequently use
- mprotect to switch write permission on and off: it's not unreasonable.
-
- I was going to add a second ipcperms check in do_shmat, to check for
- writable when readonly, and if not writable find_vma and clear VM_MAYWRITE.
- But security_ipc_permission might do auditing, and it seems wrong to
- report an attempt for write permission when there has been none. Or we
- could flag the vma as SHM, note the shmid or shp in vm_private_data, and
- then get mprotect to check.
-
- But the patch below is a lot simpler: I'd rather stick with it, if we can
- convince ourselves somehow that it'll be safe.
-
- Signed-off-by: Hugh Dickins <hugh at veritas.com>
- Signed-off-by: Andrew Morton <akpm at osdl.org>
- Signed-off-by: Greg Kroah-Hartman <gregkh at suse.de>
+Signed-off-by: Hugh Dickins <hugh at veritas.com>
+---
-diff -urpN kernel-source-2.6.8.orig/ipc/shm.c 2.6/ipc/shm.c
---- kernel-source-2.6.8.orig/ipc/shm.c 2006-02-08 22:55:57.000000000 -0700
-+++ 2.6/ipc/shm.c 2006-05-19 11:26:05.000000000 -0600
-@@ -151,6 +151,8 @@ static int shm_mmap(struct file * file,
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -161,6 +161,8 @@ static int shm_mmap(struct file * file,
{
- file_accessed(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;
More information about the Kernel-svn-changes
mailing list