/[linux-patches]/genpatches-2.6/trunk/2.6.14/1497_16.6_stop-mprotect-givin-rw-to-ro.patch
Gentoo

Contents of /genpatches-2.6/trunk/2.6.14/1497_16.6_stop-mprotect-givin-rw-to-ro.patch

Parent Directory Parent Directory | Revision Log Revision Log


Revision 427 - (show annotations) (download) (as text)
Thu Apr 20 20:16:15 2006 UTC (14 years, 7 months ago) by johnm
File MIME type: text/x-diff
File size: 2454 byte(s)
bump to fix CVE-2006-1056, CVE-2006-1525, CVE-2006-1524
1 From akpm@osdl.org Wed Apr 12 14:32:33 2006
2 Message-Id: <200604122132.k3CLW1Io021188@shell0.pdx.osdl.net>
3 Subject: shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524)
4 To: greg@kroah.com
5 Cc: chrisw@sous-sol.org, akpm@osdl.org, hugh@veritas.com, stable@kernel.org
6 From: akpm@osdl.org
7 Date: Wed, 12 Apr 2006 14:34:27 -0700
8
9
10 From: Hugh Dickins <hugh@veritas.com>
11
12 I found that all of 2.4 and 2.6 have been letting mprotect give write
13 permission to a readonly attachment of shared memory, whether or not IPC
14 would give the caller that permission.
15
16 SUS says "The behaviour of this function [mprotect] is unspecified if the
17 mapping was not established by a call to mmap", but I don't think we can
18 interpret that as allowing it to subvert IPC permissions.
19
20 I haven't tried 2.2, but the 2.2.26 source looks like it gets it right; and
21 the patch below reproduces that behaviour - mprotect cannot be used to add
22 write permission to a shared memory segment attached readonly.
23
24 This patch is simple, and I'm sure it's what we should have done in 2.4.0:
25 if you want to go on to switch write permission on and off with mprotect,
26 just don't attach the segment readonly in the first place.
27
28 However, we could have accumulated apps which attach readonly (even though
29 they would be permitted to attach read/write), and which subsequently use
30 mprotect to switch write permission on and off: it's not unreasonable.
31
32 I was going to add a second ipcperms check in do_shmat, to check for
33 writable when readonly, and if not writable find_vma and clear VM_MAYWRITE.
34 But security_ipc_permission might do auditing, and it seems wrong to
35 report an attempt for write permission when there has been none. Or we
36 could flag the vma as SHM, note the shmid or shp in vm_private_data, and
37 then get mprotect to check.
38
39 But the patch below is a lot simpler: I'd rather stick with it, if we can
40 convince ourselves somehow that it'll be safe.
41
42 Signed-off-by: Hugh Dickins <hugh@veritas.com>
43 Signed-off-by: Andrew Morton <akpm@osdl.org>
44 Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
45
46 ---
47 ipc/shm.c | 2 ++
48 1 file changed, 2 insertions(+)
49
50 --- linux-2.6.16.5.orig/ipc/shm.c
51 +++ linux-2.6.16.5/ipc/shm.c
52 @@ -159,6 +159,8 @@ static int shm_mmap(struct file * file,
53 {
54 file_accessed(file);
55 vma->vm_ops = &shm_vm_ops;
56 + if (!(vma->vm_flags & VM_WRITE))
57 + vma->vm_flags &= ~VM_MAYWRITE;
58 shm_inc(file->f_dentry->d_inode->i_ino);
59 return 0;
60 }

  ViewVC Help
Powered by ViewVC 1.1.20