unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Undefined behavior in OS X unexec detected by ASan
@ 2016-04-02 17:26 Philipp Stephani
  2016-04-08  8:27 ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Philipp Stephani @ 2016-04-02 17:26 UTC (permalink / raw)
  To: Emacs developers


[-- Attachment #1.1: Type: text/plain, Size: 237 bytes --]

unexmacosx.c reads process memory directly, which tends to work in practice
but is technically undefined behavior. I've attached a small patch that
uses vm_read instead. According to ASan with this patch there's no more UB
when dumping.

[-- Attachment #1.2: Type: text/html, Size: 267 bytes --]

[-- Attachment #2: 0001-Remove-undefined-behavior-in-OS-X-dumper.patch --]
[-- Type: application/octet-stream, Size: 1894 bytes --]

From cbf0d88b109254ae82fcc713302634d9817ba9c7 Mon Sep 17 00:00:00 2001
From: Philipp Stephani <phst@google.com>
Date: Thu, 31 Mar 2016 23:10:40 +0200
Subject: [PATCH] Remove undefined behavior in OS X dumper.

Found by Address Sanitizer.

* src/unexmacosx.c (unexec_write): Use Mach virtual memory API to
avoid undefined behavior when reading arbitrary memory.
---
 src/unexmacosx.c | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/src/unexmacosx.c b/src/unexmacosx.c
index 827eda5..bdacc8b 100644
--- a/src/unexmacosx.c
+++ b/src/unexmacosx.c
@@ -103,9 +103,11 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #include <stdio.h>
 #include <fcntl.h>
 #include <stdarg.h>
+#include <stdint.h>
 #include <sys/types.h>
 #include <unistd.h>
 #include <mach/mach.h>
+#include <mach/vm_map.h>
 #include <mach-o/loader.h>
 #include <mach-o/reloc.h>
 #ifdef HAVE_MALLOC_MALLOC_H
@@ -217,10 +219,27 @@ unexec_read (void *dest, size_t n)
 static int
 unexec_write (off_t dest, const void *src, size_t count)
 {
+  task_t task = mach_task_self();
+  if (task == MACH_PORT_NULL || task == MACH_PORT_DEAD)
+    return false;
+
   if (lseek (outfd, dest, SEEK_SET) != dest)
     return 0;
 
-  return write (outfd, src, count) == count;
+  /* We use the Mach virtual memory API to read our process memory
+     because using src directly would be undefined behavior and fails
+     under Address Sanitizer.  */
+  bool success = false;
+  vm_offset_t data;
+  mach_msg_type_number_t data_count;
+  if (vm_read (task, (uintptr_t) src, count, &data, &data_count)
+      == KERN_SUCCESS)
+    {
+      success =
+        write (outfd, (const void *) (uintptr_t) data, data_count) == count;
+      vm_deallocate (task, data, data_count);
+    }
+  return success;
 }
 
 /* Write COUNT bytes of zeros to outfd starting at offset DEST.
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: Undefined behavior in OS X unexec detected by ASan
  2016-04-02 17:26 Undefined behavior in OS X unexec detected by ASan Philipp Stephani
@ 2016-04-08  8:27 ` Eli Zaretskii
  2016-04-08 16:01   ` John Wiegley
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2016-04-08  8:27 UTC (permalink / raw)
  To: Philipp Stephani, John Wiegley; +Cc: emacs-devel

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 02 Apr 2016 17:26:17 +0000
> 
> unexmacosx.c reads process memory directly, which tends to work in practice but is technically undefined
> behavior. I've attached a small patch that uses vm_read instead. According to ASan with this patch there's no
> more UB when dumping.

Would someone who uses OS X please see if this patch is OK?  Are there
any version-related caveats here (e.g., could some older OS X version
have trouble with this change)?

If everything's fine with the patch, we still need to decide to which
branch this should go.  John?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Undefined behavior in OS X unexec detected by ASan
  2016-04-08  8:27 ` Eli Zaretskii
@ 2016-04-08 16:01   ` John Wiegley
  2016-05-15 19:36     ` Philipp Stephani
  0 siblings, 1 reply; 6+ messages in thread
From: John Wiegley @ 2016-04-08 16:01 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Philipp Stephani, emacs-devel

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Would someone who uses OS X please see if this patch is OK? Are there any
> version-related caveats here (e.g., could some older OS X version have
> trouble with this change)?

> If everything's fine with the patch, we still need to decide to which branch
> this should go. John?

I'll give it a try. If it still looks good next week, then I think emacs-25
would be fine, since this isn't new behavior but just a correction.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Undefined behavior in OS X unexec detected by ASan
  2016-04-08 16:01   ` John Wiegley
@ 2016-05-15 19:36     ` Philipp Stephani
  2016-05-15 19:54       ` Paul Eggert
  0 siblings, 1 reply; 6+ messages in thread
From: Philipp Stephani @ 2016-05-15 19:36 UTC (permalink / raw)
  To: Eli Zaretskii, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

John Wiegley <jwiegley@gmail.com> schrieb am Fr., 8. Apr. 2016 um 18:02 Uhr:

> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Would someone who uses OS X please see if this patch is OK? Are there any
> > version-related caveats here (e.g., could some older OS X version have
> > trouble with this change)?
>
> > If everything's fine with the patch, we still need to decide to which
> branch
> > this should go. John?
>
> I'll give it a try. If it still looks good next week, then I think emacs-25
> would be fine, since this isn't new behavior but just a correction.
>
>
Friendly ping?

[-- Attachment #2: Type: text/html, Size: 995 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Undefined behavior in OS X unexec detected by ASan
  2016-05-15 19:36     ` Philipp Stephani
@ 2016-05-15 19:54       ` Paul Eggert
  2016-05-15 19:58         ` Philipp Stephani
  0 siblings, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2016-05-15 19:54 UTC (permalink / raw)
  To: Philipp Stephani, emacs-devel

Philipp Stephani wrote:
> Friendly ping?

That patch was committed to the emacs-25 branch and merged to master on April 9.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Undefined behavior in OS X unexec detected by ASan
  2016-05-15 19:54       ` Paul Eggert
@ 2016-05-15 19:58         ` Philipp Stephani
  0 siblings, 0 replies; 6+ messages in thread
From: Philipp Stephani @ 2016-05-15 19:58 UTC (permalink / raw)
  To: Paul Eggert, emacs-devel

[-- Attachment #1: Type: text/plain, Size: 220 bytes --]

Paul Eggert <eggert@cs.ucla.edu> schrieb am So., 15. Mai 2016 um 21:54 Uhr:

> Philipp Stephani wrote:
> > Friendly ping?
>
> That patch was committed to the emacs-25 branch and merged to master on
> April 9.
>

Thanks!

[-- Attachment #2: Type: text/html, Size: 503 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-05-15 19:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-02 17:26 Undefined behavior in OS X unexec detected by ASan Philipp Stephani
2016-04-08  8:27 ` Eli Zaretskii
2016-04-08 16:01   ` John Wiegley
2016-05-15 19:36     ` Philipp Stephani
2016-05-15 19:54       ` Paul Eggert
2016-05-15 19:58         ` Philipp Stephani

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).