From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org
Cc: Hugh Dickins <hugh@veritas.com>, Andrew Morton <akpm@osdl.org>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: [PATCH 5/5] shmat: stop mprotect from giving write permission to a readonly attachment (CVE-2006-1524)
Date: Mon, 17 Apr 2006 14:33:39 -0700 [thread overview]
Message-ID: <11453096192342-git-send-email-greg@kroah.com> (raw)
In-Reply-To: <11453096192073-git-send-email-greg@kroah.com>
From: Hugh Dickins <hugh@veritas.com>
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@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
ipc/shm.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
b78b6af66a5fbaf17d7e6bfc32384df5e34408c8
diff --git a/ipc/shm.c b/ipc/shm.c
index 6b0c9af..1c2faf6 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -162,6 +162,8 @@ static int shm_mmap(struct file * file,
ret = shmem_mmap(file, vma);
if (ret == 0) {
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);
}
--
1.2.6
next prev parent reply other threads:[~2006-04-17 21:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 21:29 [GIT PATCH] Fixes in the -stable tree, but not in mainline Greg KH
2006-04-17 21:33 ` [PATCH 1/5] isd200: limit to BLK_DEV_IDE Greg KH
2006-04-17 21:33 ` [PATCH 2/5] Fix block device symlink name Greg KH
2006-04-17 21:33 ` [PATCH 3/5] ext3: Fix missed mutex unlock Greg KH
2006-04-17 21:33 ` [PATCH 4/5] cciss: bug fix for crash when running hpacucli Greg KH
2006-04-17 21:33 ` Greg KH [this message]
2006-04-18 16:06 ` [GIT PATCH] Fixes in the -stable tree, but not in mainline Theodore Ts'o
2006-04-18 17:42 ` Greg KH
2006-04-18 20:39 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11453096192342-git-send-email-greg@kroah.com \
--to=greg@kroah.com \
--cc=akpm@osdl.org \
--cc=gregkh@suse.de \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox