wok-current 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 +