From: Neil Horman <nhorman@redhat.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH] close race condition in shared memory mapping/unmapping
Date: Mon, 13 Sep 2004 16:33:35 -0400 [thread overview]
Message-ID: <4146041F.2040106@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
Hey all-
Found this the other day poking through the ipc code. There appears to
be a race condition in the counter that records how many processes are
accessing a given shared memory segment. In most places the shm_nattch
variable is protected by the shm_ids.sem semaphore, but there are a few
openings which appear to be able to allow a corruption of this variable
when run on SMP systems. I've attached a patch to 2.6.9-rc2 for review.
The locking may be a little over-aggressive (I was following examples
from other points in this file), but I figure better safe than sorry :).
Anywho, here it is.
Thanks
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
[-- Attachment #2: linux-2.6.9-rc2-shmlock.patch --]
[-- Type: text/plain, Size: 1325 bytes --]
--- linux-2.6.9-rc2-rpc/ipc/shm.c.orig 2004-09-13 15:59:46.604446096 -0400
+++ linux-2.6.9-rc2-rpc/ipc/shm.c 2004-09-13 16:17:05.606493776 -0400
@@ -86,12 +86,14 @@
static inline void shm_inc (int id) {
struct shmid_kernel *shp;
+ down(&shm_ids.sem);
if(!(shp = shm_lock(id)))
BUG();
shp->shm_atim = get_seconds();
shp->shm_lprid = current->tgid;
shp->shm_nattch++;
shm_unlock(shp);
+ up(&shm_ids.sem);
}
/* This is called by fork, once for every shm attach. */
@@ -697,18 +699,23 @@
* We cannot rely on the fs check since SYSV IPC does have an
* additional creator id...
*/
+ down(&shm_ids.sem);
shp = shm_lock(shmid);
if(shp == NULL) {
+ shm_unlock(shp);
+ up(&shm_ids.sem);
err = -EINVAL;
goto out;
}
err = shm_checkid(shp,shmid);
if (err) {
shm_unlock(shp);
+ up(&shm_ids.sem);
goto out;
}
if (ipcperms(&shp->shm_perm, acc_mode)) {
shm_unlock(shp);
+ up(&shm_ids.sem);
err = -EACCES;
goto out;
}
@@ -716,6 +723,7 @@
err = security_shm_shmat(shp, shmaddr, shmflg);
if (err) {
shm_unlock(shp);
+ up(&shm_ids.sem);
return err;
}
@@ -723,6 +731,7 @@
size = i_size_read(file->f_dentry->d_inode);
shp->shm_nattch++;
shm_unlock(shp);
+ up(&shm_ids.sem);
down_write(¤t->mm->mmap_sem);
if (addr && !(shmflg & SHM_REMAP)) {
next reply other threads:[~2004-09-13 20:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-13 20:33 Neil Horman [this message]
2004-09-13 20:49 ` [PATCH] close race condition in shared memory mapping/unmapping Felipe W Damasio
2004-09-13 20:54 ` Neil Horman
2004-09-13 21:01 ` Chris Wright
2004-09-14 11:48 ` Neil Horman
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=4146041F.2040106@redhat.com \
--to=nhorman@redhat.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