Re: integer overflow in xemacs
Ar an chéad lá is fiche de mí Eanair, scríobh Nico Golde:
Hi,
during the analysis of CVE-2007-6109 and if this affects
xemacs Florian Weimer and me recognized a problem in the
xemacs code:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457764#10
[whence]
It turned out that this is actually no bug in the quoted
code because the precision is taken into account when
reserving memory for the buffer. Unfortunately this is the
problem because:
#define alloca_array(type, len) ((type *) alloca ((len) * sizeof (type)))
this does not do any checks and also includes an integer
overflow and thus it is still possible to reproduce this
problem. So the obvious thing is to fix this macro which
should be quite important because alloca_array is used at a
bunch of different places in the code.
(format "%.*d" -1 25)
=> "25"
I don’t see any bug here. The particular use of alloca_array you’re talking
about has its length argument checked; it’s zero at a minimum. The function
#'gtk-pixmap-get in ui-byhand.c doesn’t check that the argument to
alloca_array is non-negative, but anyone who can call #'gtk-pixmap-get
mailiciously can call #'make-vector maliciously too, where allocating memory
is the documented and intentional behaviour of the API.
--
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta