From: ebiederm+eric@ccr.net (Eric W. Biederman)
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.rutgers.edu
Subject: PATHC: SHM mappings beyond the end of a segment.
Date: 29 Jan 2000 22:28:42 -0600 [thread overview]
Message-ID: <m17lgsgp39.fsf@flinx.hidden> (raw)
Currently it is possible to extend the vma for a shm segment
with mremap. The shm code has no checks for access beyond the
end of the shm segment. Resulting in writes to shp->shm_dir in 2.3
and shp->shm_pages in 2.2 past the allocated end of the array.
By playing with this processes can create weird memory overwrites,
and effectively mlocked private pages.
As using mremap to extend a shm mapping is basically silly,
and linux specific. I don't think it affects anything in practice.
The attached patch caused SIGBUS to be delivered when
we write past the end of our shm area.
Eric
===File linux-2.3.41.eb1.diff==============
diff -uNrX linux-ignore-files linux-2.3.41/ipc/shm.c linux-2.3.41.eb1/ipc/shm.c
--- linux-2.3.41/ipc/shm.c Mon Jan 24 13:04:37 2000
+++ linux-2.3.41.eb1/ipc/shm.c Sat Jan 29 18:57:58 2000
@@ -840,6 +840,15 @@
idx = (address - shmd->vm_start) >> PAGE_SHIFT;
idx += shmd->vm_pgoff;
+ /*
+ * A shared mapping past the last page of the file is an error
+ * and results in a SIGBUS, so logically a shared mapping past
+ * the end of a shared memory segment should result in SIGBUS
+ * as well.
+ */
+ if (idx >= shp->shm_npages) {
+ return NULL;
+ }
down(&shp->sem);
if(shp != shm_lock(shp->id))
BUG();
============================================================
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
reply other threads:[~2000-01-30 4:28 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=m17lgsgp39.fsf@flinx.hidden \
--to=ebiederm+eric@ccr.net \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=torvalds@transmeta.com \
/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