[kernel] r6617 - in dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27: debian debian/patches/series

[Dann Frazier]

Author: dannf
Date: Sat May 20 00:41:33 2006
New Revision: 6617

Added:
   dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/213_madvise_remove-restrict.diff
Modified:
   dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/changelog
   dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/series/2.4.27-10sarge3

Log:
* 213_madvise_remove-restrict.diff
  [SECURITY] Fix vulnerability that allows local users to bypass IPC
  permissions and replace portions of read-only tmpfs files with zeroes.
  See CVE-2006-1524

Added: dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/213_madvise_remove-restrict.diff
==============================================================================
--- (empty file)
+++ dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/213_madvise_remove-restrict.diff	Sat May 20 00:41:33 2006
@@ -0,0 +1,57 @@
+Trivial backport of the origional pattch. This patch will apply to both Sarge
+2.4.27 and 2.6.8. 
+
+Signed-off-by: Troy Heber <troyh at debian.org>
+
+diff-tree 512dba41bae0ec8de72269167f23b75a4770097d (from 23e0ac040b8052729c32dfec78f751d82515e73e)
+Author: Hugh Dickins <hugh at veritas.com>
+Date:   Wed Apr 12 14:34:27 2006 -0700
+
+    [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>
+
+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, 
+ {
+ 	file_accessed(file);
+ 	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;
+ }

Modified: dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/changelog
==============================================================================
--- dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/changelog	(original)
+++ dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/changelog	Sat May 20 00:41:33 2006
@@ -23,8 +23,12 @@
   * 212_ipv4-sin_zero_clear.diff
     [SECURITY] Fix local information leak in af_inet code
     See CVE-2006-1342
+  * 213_madvise_remove-restrict.diff
+    [SECURITY] Fix vulnerability that allows local users to bypass IPC
+    permissions and replace portions of read-only tmpfs files with zeroes.
+    See CVE-2006-1524
 
- -- dann frazier <dannf at debian.org>  Fri, 19 May 2006 19:24:12 -0500
+ -- dann frazier <dannf at debian.org>  Fri, 19 May 2006 19:38:55 -0500
 
 kernel-source-2.4.27 (2.4.27-10sarge2) stable-security; urgency=high
 

Modified: dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/series/2.4.27-10sarge3
==============================================================================
--- dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/series/2.4.27-10sarge3	(original)
+++ dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27/debian/patches/series/2.4.27-10sarge3	Sat May 20 00:41:33 2006
@@ -4,3 +4,4 @@
 + 210_ipv4-id-no-increment.diff
 + 211_usb-gadget-rndis-bufoverflow.diff
 + 212_ipv4-sin_zero_clear.diff
++ 213_madvise_remove-restrict.diff