wok rev 2589

glib: Security fix (http://labs.slitaz.org/issues/show/32)
author Christophe Lincoln <pankso@slitaz.org>
date Wed Apr 08 10:36:15 2009 +0200 (2009-04-08)
parents ee8706874a32
children ee6456d289bd
files glib/receipt glib/stuff/glib-CVE-2008-4316.diff
line diff
     1.1 --- a/glib/receipt	Tue Apr 07 22:59:27 2009 +0200
     1.2 +++ b/glib/receipt	Wed Apr 08 10:36:15 2009 +0200
     1.3 @@ -14,6 +14,8 @@
     1.4  compile_rules()
     1.5  {
     1.6  	cd $src
     1.7 +	# Security fix (http://labs.slitaz.org/issues/show/32)
     1.8 +	patch -p 0 < ../stuff/glib-CVE-2008-4316.diff || exit 1
     1.9  	./configure \
    1.10  		--prefix=/usr \
    1.11  		--sysconfdir=/etc \
     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/glib/stuff/glib-CVE-2008-4316.diff	Wed Apr 08 10:36:15 2009 +0200
     2.3 @@ -0,0 +1,62 @@
     2.4 +--- glib/gbase64.c	2009/02/23 04:30:06	7897
     2.5 ++++ glib/gbase64.c	2009/03/12 13:30:55	7973
     2.6 +@@ -54,8 +54,9 @@
     2.7 +  *
     2.8 +  * The output buffer must be large enough to fit all the data that will
     2.9 +  * be written to it. Due to the way base64 encodes you will need
    2.10 +- * at least: @len * 4 / 3 + 6 bytes. If you enable line-breaking you will
    2.11 +- * need at least: @len * 4 / 3 + @len * 4 / (3 * 72) + 7 bytes.
    2.12 ++ * at least: (@len / 3 + 1) * 4 + 4 bytes (+ 4 may be needed in case of
    2.13 ++ * non-zero state). If you enable line-breaking you will need at least:
    2.14 ++ * ((@len / 3 + 1) * 4 + 4) / 72 + 1 bytes of extra space.
    2.15 +  *
    2.16 +  * @break_lines is typically used when putting base64-encoded data in emails.
    2.17 +  * It breaks the lines at 72 columns instead of putting all of the text on 
    2.18 +@@ -233,8 +234,14 @@
    2.19 +   g_return_val_if_fail (data != NULL, NULL);
    2.20 +   g_return_val_if_fail (len > 0, NULL);
    2.21 + 
    2.22 +-  /* We can use a smaller limit here, since we know the saved state is 0 */
    2.23 +-  out = g_malloc (len * 4 / 3 + 4);
    2.24 ++  /* We can use a smaller limit here, since we know the saved state is 0,
    2.25 ++     +1 is needed for trailing \0, also check for unlikely integer overflow */
    2.26 ++  if (len >= ((G_MAXSIZE - 1) / 4 - 1) * 3)
    2.27 ++    g_error("%s: input too large for Base64 encoding (%"G_GSIZE_FORMAT" chars)",
    2.28 ++        G_STRLOC, len);
    2.29 ++
    2.30 ++  out = g_malloc ((len / 3 + 1) * 4 + 1);
    2.31 ++
    2.32 +   outlen = g_base64_encode_step (data, len, FALSE, out, &state, &save);
    2.33 +   outlen += g_base64_encode_close (FALSE, out + outlen, &state, &save);
    2.34 +   out[outlen] = '\0';
    2.35 +@@ -275,7 +282,8 @@
    2.36 +  *
    2.37 +  * The output buffer must be large enough to fit all the data that will
    2.38 +  * be written to it. Since base64 encodes 3 bytes in 4 chars you need
    2.39 +- * at least: @len * 3 / 4 bytes.
    2.40 ++ * at least: (@len / 4) * 3 + 3 bytes (+ 3 may be needed in case of non-zero
    2.41 ++ * state).
    2.42 +  * 
    2.43 +  * Return value: The number of bytes of output that was written
    2.44 +  *
    2.45 +@@ -358,7 +366,8 @@
    2.46 + 		 gsize       *out_len)
    2.47 + {
    2.48 +   guchar *ret;
    2.49 +-  gint input_length, state = 0;
    2.50 ++  gsize input_length;
    2.51 ++  gint state = 0;
    2.52 +   guint save = 0;
    2.53 +   
    2.54 +   g_return_val_if_fail (text != NULL, NULL);
    2.55 +@@ -368,7 +377,9 @@
    2.56 + 
    2.57 +   g_return_val_if_fail (input_length > 1, NULL);
    2.58 + 
    2.59 +-  ret = g_malloc0 (input_length * 3 / 4);
    2.60 ++  /* We can use a smaller limit here, since we know the saved state is 0,
    2.61 ++     +1 used to avoid calling g_malloc0(0), and hence retruning NULL */
    2.62 ++  ret = g_malloc0 ((input_length / 4) * 3 + 1);
    2.63 +   
    2.64 +   *out_len = g_base64_decode_step (text, input_length, ret, &state, &save);
    2.65 +