[kernel] r6617 - in
dists/sarge-security/kernel-2.4/source/kernel-source-2.4.27-2.4.27:
debian debian/patches/series
Dann Frazier
dannf at costa.debian.org
Sat May 20 00:41:34 UTC 2006
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
More information about the Kernel-svn-changes
mailing list