GNU bug report logs - #24118
25.1; [PATCH] Fix a possible crash caused by mapcar1

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Chris Feng <chris.w.feng <at> gmail.com>
Subject: bug#24118: closed (Re: 25.1; [PATCH] Fix a possible crash caused
 by mapcar1)
Date: Wed, 03 Aug 2016 01:17:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#24118: 25.1; [PATCH] Fix a possible crash caused by mapcar1

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 24118 <at> debbugs.gnu.org.

-- 
24118: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24118
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Chris Feng <chris.w.feng <at> gmail.com>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 24118-done <at> debbugs.gnu.org
Subject: Re: 25.1; [PATCH] Fix a possible crash caused by mapcar1
Date: Tue, 2 Aug 2016 18:15:53 -0700

[Message part 3 (text/plain, inline)]

Thanks for the bug report. I installed the attached more-adventurous patch, 
which truncates the result rather than extending it with nils. This seems a bit 
more appropriate anyway.

Although it no longer matters for this patch, memclear is specified to store nil 
values regardless of how nil is represented. Of course memclear's current 
implementation assumes Qnil is zero, and memclear can't be portably and easily 
implemented if we merely change Qnil to be nonzero, but that's a bridge we don't 
have to cross unless we change Qnil to be nonzero.

[0001-Fix-mapcar-F-S-crash-when-F-alters-S-s-length.txt (text/plain, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Chris Feng <chris.w.feng <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; [PATCH] Fix a possible crash caused by mapcar1
Date: Sun, 31 Jul 2016 20:46:50 +0800

Processing a list with `mapcar' or `mapconcat' can be terminated early
when the list is tampered (as shown in the following example), and as a
result we'll be dealing with uninitialized memory which will likely
trigger a crash.

  (setq a (make-list 10 0))
  (mapcar (lambda (_)
            (setcdr a nil))
          a)

Chris

---

* src/fns.c (mapcar1): Check and reset uninitialized list elements.
---
 src/fns.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/src/fns.c b/src/fns.c
index d5a1f74..1804bce 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2524,6 +2524,10 @@ mapcar1 (EMACS_INT leni, Lisp_Object *vals, Lisp_Object fn, Lisp_Object seq)
 	    vals[i] = dummy;
 	  tail = XCDR (tail);
 	}
+
+      /* In case the list was tampered and the loop terminated early. */
+      if (i < leni)
+        memclear (vals + i, (leni - i) * word_size);
     }
 }
 
-- 
2.8.1

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.