[kernel] r6747 - dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches

[Dann Frazier]

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;