GNU bug report logs - #9196
integer and memory overflow issues (e.g., cut-and-paste crashes Emacs)

Previous Next

Full log

Message #8 received at 9196 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9196 <at> debbugs.gnu.org
Subject: Re: bug#9196: integer and memory overflow issues (e.g., cut-and-paste
	crashes Emacs)
Date: Fri, 29 Jul 2011 12:01:15 +0200

Hello.

Since strlen is defined to return size_t and you store the result in a 
ptrdiff_t, does not that mean you have introduced a possible signed/unsigned 
conversion error?

 In gtkutil.c:

+      ptrdiff_t lim = min (TYPE_MAXIMUM (Window),
+			   min (PTRDIFF_MAX, SIZE_MAX) / sizeof (GtkWidget *));

Isn't this a compile time constant?  Should it not be a #define or something?
IMHO, the check in gtkutil.c will only call memory_full when there is 2^31 
(about 2 billion) scroll bars in Emacs.  Isn't it overengineering to check for 
that case?


In xgselect.c:

+	int gfds_size_max =
+	  min (INT_MAX, min (PTRDIFF_MAX, SIZE_MAX) / sizeof *gfds);

Here a compile time constant is recalculated inside a loop.
The xgselect.c is also overengineering IMHO.  The number checked represents 
the number of file descriptor sources Glib is checking.  I can understand 
checking sizes for strings that come from external sources, but only code adds 
file descriptor sources.  If some bug causes the addition of 2 billion 
sources, a crash would be fine by me.  Actually better than memory_full, 
because the core is much more useful.

I haven't looked at the other files.  I hope to find time to look at xselect.c 
at least.

	Jan D.

Previous Next

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