[E-devel] Imlib2 patch
Hi All, I wrote new version of some procedures in Imlib2 library and attached patches for that mail. In file color-helpres procedures : void __imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v ); void __imlib_hsv_to_rgb( float h, float s, float v, int *r, int *g, int *b ); I have changed the range of parameters hue from 0-100 to 0-360, and saturation and value from 0-100 to 0-1. This is correct to last version of documentation on the web page. In file grad.c procedures : void __imlib_MapRange( ImlibRange * rg, int len ) void __imlib_MapHsvaRange( ImlibRange * rg, int len ) I have changed internal variable inc from: inc = ((ll - 1) << 16) / (len); to: inc = ((ll - 1) << 16) / (len-1); This patch repair bug for small values of parameter len, for example from 2 to 16. And I apply two small screenshots of application imlib2_colorspace befor and after patch. Best Regards -- Dariusz Knociński - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 patch
Patch:
diff -u -p -r imlib2-1.4.1.000.old/src/lib/color_helpers.c
imlib2-1.4.1.000.new/src/lib/color_helpers.c
--- imlib2-1.4.1.000.old/src/lib/color_helpers.c2007-05-21
00:58:01.0 +0200
+++ imlib2-1.4.1.000.new/src/lib/color_helpers.c2008-04-15
09:34:36.0 +0200
@@ -5,117 +5,89 @@
*/
void
-__imlib_rgb_to_hsv(int r, int g, int b, float *h, float *s, float *v)
+__imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v )
{
- int min, max;
- int delta;
+ register float min, max, delta;
- max = (r + g + abs(r - g)) / 2;
- max = (max + b + abs(max - b)) / 2;
- min = (r + g - abs(r - g)) / 2;
- min = (min + b - abs(min - b)) / 2;
+min = ((( r < g ) ? r : g) < b ) ? (( r < g ) ? r : g) : b;
+max = ((( r > g ) ? r : g) > b ) ? (( r > g ) ? r : g) : b;
- delta = max - min;
- *v = (float)(100 * max) / 255.0;
-
- if (max != 0)
- *s = (float)(100 * delta) / (float)max;
- else
- {
-*s = 0.0;
+*v = max / 255.0;
+ delta = ( max - min );
+if( delta == 0 )
+{
*h = 0.0;
-*v = 0.0;
- }
- if (r == max)
- {
-*h = (float)(100 * (g - b)) / (float)(6.0 * delta);
- }
- else
- {
-if (g == max)
- {
- *h = (float)(100 * (2 * delta + b - r)) / (float)(6.0 * delta);
- }
-else
- {
- *h = (float)(100 * (4 * delta + r - g)) / (float)(6.0 * delta);
- }
- }
- if (*h < 0.0)
- *h += 100.0;
- if (*h > 100.0)
- *h -= 100.0;
+*s = 0.0;
+return;
+}
+*s = delta / max;
+ if( r == max )
+ *h = ( g - b ) / delta;
+ else if( g == max )
+ *h = 2.0 + ( b - r ) / delta;
+ else
+ *h = 4.0 + ( r - g ) / delta;
+ *h *= 60.0;
+ if( *h < 0 )
+ *h += 360.0;
}
void
__imlib_hsv_to_rgb(float h, float s, float v, int *r, int *g, int *b)
{
- float hh, f;
- float p, q, t;
- int i;
+register float f, vf;
+register int i, p, q, t, vv;
- if (s == 0.0)
- {
-*r = round((v * 255.0) / 100.0);
-*g = round((v * 255.0) / 100.0);
-*b = round((v * 255.0) / 100.0);
+vf = 255.0 * v;
+vv = (int)round( vf );
+if( s == 0.0 )
+{
+*r = *g = *b = vv;
return;
- }
-
- hh = (h * 6.0) / 100.0;
- i = floor(hh);
- f = hh - (float)i;
-
- p = v * (1.0 - s / 100.0) / 100.0;
- q = v * (1.0 - (s * f) / 100.0) / 100.0;
- t = v * (1.0 - s * (1.0 - f) / 100.0) / 100.0;
+}
- switch (i)
- {
- case 0:
-{
- *r = round(v * 255.0 / 100.0);
- *g = round(t * 255.0);
- *b = round(p * 255.0);
- break;
-}
- case 1:
-{
- *r = round(q * 255.0);
- *g = round(v * 255.0 / 100.0);
- *b = round(p * 255.0);
- break;
-}
- case 2:
-{
- *r = round(p * 255.0);
- *g = round(v * 255.0 / 100.0);
- *b = round(t * 255.0);
- break;
-}
- case 3:
-{
- *r = round(p * 255.0);
- *g = round(q * 255.0);
- *b = round(v * 255.0 / 100.0);
- break;
-}
- case 4:
-{
- *r = round(t * 255.0);
- *g = round(p * 255.0);
- *b = round(v * 255.0 / 100.0);
- break;
-}
- case 5:
-{
- *r = round(v * 255.0 / 100.0);
- *g = round(p * 255.0);
- *b = round(q * 255.0);
- break;
-}
- }
+h /= 60.0;
+i = floor(h);
+f = h - (float)i;
+p = (int)round( vf * (1.0 - s ));
+q = (int)round( vf * (1.0 - (s * f)));
+t = (int)round( vf * (1.0 - s * (1.0 - f)));
+
+switch( i % 6 )
+{
+case 0:
+*r = vv;
+*g = t;
+*b = p;
+break;
+case 1:
+*r = q;
+*g = vv;
+*b = p;
+break;
+case 2:
+*r = p;
+*g = vv;
+*b = t;
+break;
+case 3:
+*r = p;
+*g = q;
+*b = vv;
+break;
+case 4:
+*r = t;
+*g = p;
+*b = vv;
+break;
+case 5:
+default:
+*r = vv;
+*g = p;
+*b = q;
+break;
+}
}
void
diff -u -p -r imlib2-1.4.1.000.old/src/lib/grad.c
imlib2-1.4.1.000.new/src/lib/grad.c
--- imlib2-1.4.1.000.old/src/lib/grad.c 2007-05-21 00:58:01.0 +0200
+++ imlib2-1.4.1.000.new/src/lib/grad.c 2008-04-15 09:29:32.0 +0200
@@ -112,7 +112,7 @@ __imlib_MapRange(ImlibRange * rg, int le
pmap[i++] = (a << 24) | (r << 16) | (g << 8) | b;
}
}
- inc = ((ll - 1) << 16) / (len);
+ inc = ((ll - 1) << 16) / (len-1);
l = 0;
for (i = 0; i < len; i++)
{
@@ -194,7 +194,7 @@ __imlib_MapHsvaRan
Re: [E-devel] Imlib2 patch
BEGIN BASE64 imlib2_colorspace-before.jpg /9j/4AAQSkZJRgABAQEASABIAAD/4QAWRXhpZgAATU0AKggAAAD/2wBDAAUDBAQEAwUE BAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/ 2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh7/wAARCAGpAl8DASIAAhEBAxEB/8QAHAABAAICAwEAAAEHBQYC AwgE/8QAUhAAAQMCAgIMCggEBAQFBQEAAAECAwQFBhESMQcUFhchVFV1lJXR0xNBUVJWk6Gis9IV IjI1NjhhsnGBtNQjJEKRCFNiZTNDY3KCJbG1wfE3/8QAGwEBAQEBAAMBAAMBAgQF Bwb/xABHEQACAQECBwsJBgYDAQADAQIRAwQFEyExUXGRBhIVFzRBUlOhsdIUFjJhcpKi0eEH M0JDVIEiNXODsvDBwvFiI0SC/9oADAMBAAIRAxEAPwC2thbYxsWAsMW6GG1UFTf6ima6vuErUlc9 0iNc5jFc1Mo0ybkmSauHNVVV3ioWKnkVk1voEy4UclI1UX2GQoocrfQ1GXB4GDh/+LUMPiCdEcvC uo86xhj5/wAR49pJ2Uf4Ttp5qWoRyw0dudou0Xf5VqZL/sduUfELf0VnYY/AkK1MVwfkq5VOXuob LtBfN9hO2irO0cdBSzk5RTZiso+IW/orOwZR8Qt/RWdhldoL5vsG0F832Eqo7MVlHxC39FZ2DKPi Fv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv 6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6K zsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6Kzs MrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMr tBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtB fN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN 9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g 2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2g vm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm +wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+w VQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQ MVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMV lHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlH xC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC 39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMVlHxC39FZ2DKPiFv6KzsMrtBfN9g2gvm+wVQMdRwRVFS sS0tuia1ukqrRtdnw/yPt+i6fzbd1e3tOmVrqWtVGtVznRZo1Na5Z8CHzUl0qJZVZUW2rpE0c0fM zJq/pn5RSoE0LI65KVKW2uzc1EftNqJkv6fy8onksUEz4Zq2zskYuTmuomIqL/uS9+lOtT4mvYns cdTXwtknSotckz1nkXTW3ukzRXKqfW0VzTLLxm0BzqtqR08VTTxWyqhkRyo5tG1NX+/kU+eCWB8T ZJILdGjuDP6ORW5+TSzyz/Q5RNR9M6BsTomtfUOaxWKxUaqvVPqqiKnAqHwWSpiip5pKqRjqXRRr 6dVRXTLlwZJ4kTXpeLxHj2zaaSZ511sozhJtVeQ+uongijSRlLb5GqvB/wDT0ajuHJcnal/kef8A /i92NLC3CLsfWS3Utsr6Wpay5Nh+oyqbK5cn6CJksmm7hXNOBV15Jlel5nSasidHOyWCTR8C1uTf BNz+wrU+zl/sus1D/i8gWD/h/vmaZaVTSfGaXuNpJWiy86I4RsYRsk6czNtveOqKywU1mrbY6qY6 ihcvAioqKxNeamvrjXCKrw4Uav8A8U7TB7J/37Sc3U/7DVD9tg7AV0trtC0knVrSevnaNSaLWt2y bZLdCsNDYX08bnaStYjUzX/c+rfdouS5/d7SnweX5t3HQ9pzjpFwb7tFyXP7vaN92i5Ln93tKfA8 2rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwPNq46HtGOkXBvu0XJc/u9o33aLkuf3e0p8DzauOh7Rj pFwb7tFyXP7vaN92i5Ln93tKfA82rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwPNq46HtGOkXBvu0X Jc/u9o33aLkuf3e0p8DzauOh7RjpFwb7tFyXP7vaN92i5Ln93tKfA82rjoe0Y6RcG+7Rclz+72jf douS5/d7SnwPNq46HtGOkXBvu0XJc/u9o33aLkuf3e0p8DzauOh7RjpFwb7tFyXP7vaN92i5Ln93 tKfA82rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwPNq46HtGOkXBvu0XJc/u9o33aLkuf3e0p8Dzau Oh7RjpFwb7tFyXP7vaN92i5Ln93tKfA82rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwPNq46HtGOkX Bvu0XJc/u9o33aLkuf3e0p8DzauOh7RjpFwb7tFyXP7vaN92i5Ln93tKfA82rjoe0Y6RcG+7Rclz +72jfdouS5/d7SnwPNq46HtGOkXBvu0XJc/u9o33aLkuf3e0p8DzauOh7RjpFwb7tFyXP7vaN92i 5Ln93tKfA82rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwPNq46HtGOkXBvu0XJc/u9o33aLkuf3e0p 8DzauOh7RjpFwb7tFyXP7vaN92i5Ln93tKfA82rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwPNq46H tGOkXBvu0XJc/u9o33aLkuf3e0p8DzauOh7RjpFwb7tFyXP7vaN92i5Ln93tKfA82rjoe0Y6RcG+ 7Rclz+72jfdouS5/d7SnwPNq46HtGOkXBvu0XJc/u9o33aLkuf3e0p8DzauOh7RjpFwb7tFyXP7v aN92i5Ln93tKfA82rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwPNq46HtGOkXBvu0XJc/u9o33aLku f3e0p8DzauOh7RjpFwb7tFyXP7vaN92i5Ln93tKfA82rjoe0Y6RcG+7Rclz+72jfdouS5/d7SnwP Nq46HtGOkWjdNkm03BzHy22tY5iZI6NzUzTyaz493Nm4pdPWMK6B0tzlyXM9pmNkWazZCsrKGSk+ jK1Wvcjler26WaauHM+fdzZuKXT1jCugPN25aHtGNkWZQ7IVmpZXSJba6VVarf8AEe1URF16lQxy 4qw4qqqUF0amfAiStyQ0QHL3NXGWdPaUherWz9F0N/psXYdhqI5vo65SKxyORr5GqiqnlyML/wAT GKY8U/8ADtiCoipnQNgrKRmTss1VZWr4jWjr2U/yzYq5xo/iNPX4RwLdLnZK0sk61XP6xaXi0tU9 +65Gbfsn/ftJzdT/ALDVDa9k/wC/aTm6n/Yaoe9wPyGy1ErT0mAYfHM01Ngm+1FPLJDNFbah8ckb la5jkjcqKipwoqL4yrM6vlm+dbVPeHq8P7p7DAk4RtYOW+rmpzaz9PuZ3I3zdHjfJZxji6V3za9K tKUT0MusFK/5vli+db1PeD/N8sXzrep7w9CvtHuT/Kl2fM/U8UeGets9svAXUClU23yxfOt6nvCc qrli+db1PeHS+0W5P8qXZ8xxR4Z62z2y8BdIKWRKrli+db1PeE5VXLF863qe8Ol9oVzf5Uuz5jik wx1tntl4C6AUvlVcsXzrep7wnRquWL51vU94dLd/dH+VLs+ZnFJhjrbPbLwFzgpnRqeWL51vU94E bU8sXzrep7w6W726P8qXZ8xxS4Y62z2y8BcwKa0Knli+db1PeDQqeWL51vU94drd3dX+VLsM4pcM dbZ7ZeAuUFNoyp5XvnW9T3g0Knle+db1PeGrdzdn+VLsHFLhjrbPbLwFyApxI6jle+db1PeDwdRy vfOt6nvDtbtrs/y5dg4psMdbZ7ZeAuMFOeDqOV751vU94T4Ko5XvnW9T3h0t2d3f5b7DOKbDHW2e 2XgLiBTvgqjle+db1PeEpFPyvfOt6nvDpbsbB/lvsHFNhjrbPbLwFwgp/wAFPyvfOt6nvAkU/K98 63qe8OluvsH+W9qHFPhjrbPbLwFwAqDwM/K1863qu8HgZ+Vr51vVd4drdZYv8t7UZxT4X62z2y8B b4Kh8BNytfOt6rvB4Cbla+db1XeHS3VWT/Le1Diowv1tntl4C3gVEkE3K1863qu8HgJuVr51xVd4 dLdPZP8ALe0cVGF+ts9svAW6CovAT
Re: [E-devel] Imlib2 patch
BEGIN BASE64 imlib2_colorspace-after.jpg /9j/4AAQSkZJRgABAQEASABIAAD/4QAWRXhpZgAATU0AKggAAAD/2wBDAAUDBAQEAwUE BAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/ 2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e Hh4eHh4eHh4eHh7/wAARCAGoAl4DASIAAhEBAxEB/8QAGwAAAQUBAQEEBQYH AgP/xABWEAABAwICAwoJCQQIBAQHAQAAAQIDBAUGERIxQQcUIVRVdZSV0dMTFjI2UVKhorMVFyI1 RmGFstRCcYG0I0NERVORltIkYmWGM3KChAglY5OxwfFW/8QAGwEAAgMBAQEAAAUB AwQCBwb/xABIEQABAgMCBwwFCwQDAAMAAQIDBBEFMQYhUXGR0dIHEhMWFzI0QVOSoaJCVGGB sSIzNUNyc4OywuHwFEST8RVSwSNigv/aAAwDAQACEQMRAD8A1rcW3MbFgLDFuhhtVBU3+opmur7h K1JXPdIjXOYxXNTKNMm5JkmrhzVVVbxULFTyKya30CZcKOSkaqL7CQoocrfQ1GXB4GDh/wDS1CHx BOiOXhXUboLOHf8AKM8Rywm/JPWnmpahHLDR252i7Rd/wrUyX/I9co+IW/orOwj8CQrUxXB+SrlU 5e6hZd4L6vsK4zUhxFbkLIblc1FUiso+IW/orOwMo+IW/orOwld4L6vsDeC+r7CqqHZFZR8Qt/RW dgZR8Qt/RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWd gZR8Qt/RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdg ZR8Qt/RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZ R8Qt/RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR 8Qt/RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8 Qt/RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Q t/RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt /RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/ RWdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/R WdhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/RW dhK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/RWd hK7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/RWdh K7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/RWdhK 7wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/RWdhK7 wX1fYG8F9X2BVAIrKPiFv6KzsDKPiFv6KzsJXeC+r7A3gvq+wKoBFZR8Qt/RWdgZR8Qt/RWdhK7w X1fYG8F9X2BVAI6jgiqKlYlpbdE1rdJVWja7Ph/gPfkun9W3dXt7Txla6lrVRrVc50WaNTWuWfAg 2pLpUSyqyottXSJo5o+ZmTV+7P0hSoBNCyOuSlSltrs3NRH7zaiZL938PSE8ligmfDNW2dkjFyc1 1ExFRf8AMV79KdanY17E9jjya+Fsk6VFrkmes8i6a290maK5VT6WiuaZZbSaAd1W9I6eKpp4rZVQ yI5Uc2jamr/P0KN4JYHxNkkgt0aO4M/k5Fbn6NLPLP7jqJqPpnQNidE1r6hzWKxWKjVV6p9FURU4 FQYWSpiip5pKqRjqXRRr6dVRXTLlwZJsRNels2GeMqoqIim6VhNexyqlVxDuongijSRlLb5GqvB/ 8vRqO4clydqX+Bi//wARO4lb8U09NfsJ0dss943yrK5Vc6KCpa9Hv01a1jv6TSz4eDgXhzyTLXLz Ok1ZE6OdksEmj4Frcm+Cbn5CtTycv8l1kljGBYLI3NMtKpZ+V5ZKxnsVVRSudgM3rUpeRd7x1RWW Cms1bbHVTHUULl4EVFRWJrzUr641wiq8OFGr/wClO0g90/69pObqf8hVD7mzrClI0syI5FqqZRa+ IqOVDVrdum2S3QrDQ2F9PG52krWI1M1/zHXzu0XJc/u9pj4Gvi3I5F0nPDONg+d2i5Ln93tD53aL kuf3e0x8A4tSORdIcM42D53aLkuf3e0PndouS5/d7THwDi1I5F0hwzjYPndouS5/d7Q+d2i5Ln93 tMfAOLUjkXSHDONg+d2i5Ln93tD53aLkuf3e0x8A4tSORdIcM42D53aLkuf3e0PndouS5/d7THwD i1I5F0hwzjYPndouS5/d7Q+d2i5Ln93tMfAOLUjkXSHDONg+d2i5Ln93tD53aLkuf3e0x8A4tSOR dIcM42D53aLkuf3e0PndouS5/d7THwDi1I5F0hwzjYPndouS5/d7Q+d2i5Ln93tMfAOLUjkXSHDO Ng+d2i5Ln93tD53aLkuf3e0x8A4tSORdIcM42D53aLkuf3e0PndouS5/d7THwDi1I5F0hwzjYPnd ouS5/d7Q+d2i5Ln93tMfAOLUjkXSHDONg+d2i5Ln93tD53aLkuf3e0x8A4tSORdIcM42D53aLkuf 3e0PndouS5/d7THwDi1I5F0hwzjYPndouS5/d7Q+d2i5Ln93tMfAOLUjkXSHDONg+d2i5Ln93tD5 3aLkuf3e0x8A4tSORdIcM42D53aLkuf3e0PndouS5/d7THwDi1I5F0hwzjYPndouS5/d7Q+d2i5L n93tMfAOLUjkXSHDONg+d2i5Ln93tD53aLkuf3e0x8A4tSORdIcM42D53aLkuf3e0PndouS5/d7T HwDi1I5F0hwzjYPndouS5/d7Q+d2i5Ln93tMfAOLUjkXSHDONg+d2i5Ln93tD53aLkuf3e0x8A4t SORdIcM42D53aLkuf3e0PndouS5/d7THwDi1I5F0hwzjYPndouS5/d7Q+d2i5Ln93tMfAOLUjkXS HDONg+d2i5Ln93tD53aLkuf3e0x8A4tSORdIcM42D53aLkuf3e0PndouS5/d7THwDi1I5F0hwzjY PndouS5/d7Q+d2i5Ln93tMfAOLUjkXSHDONg+d2i5Ln93tD53aLkuf3e0x8A4tSORdIcM42D53aL kuf3e0PndouS5/d7THwDi1I5F0hwzjYPndouS5/d7Q+d2i5Ln93tMfAOLUjkXSHDONg+d2i5Ln93 tD53aLkuf3e0x8A4tSORdIcM42D53aLkuf3e0PndouS5/d7THwDi1I5F0hwzjUbpuk2m4OY+W21r HMTJHRuamaejWM/HmzcUun/3GGdAdJg5JJ1LpI4VxprN0KysoZKT5MrVa9yOV6vbpZpq4cxv482b il0/+4wzoA4uyWRdIcK40yh3QrNSyukS210qq1W/0j2qiIuvUqEcuKsOKqqlBdGpnwIkrckKIByu DUi69F0ljJqLD5q0L/TYuw7DURzfJ1ykVjkcjXyNVFVPTkWetxTHinDT6iKmdA2CsYzJ2WaqrHrs MZL7gfzKrecY/huFVr2LKScssSEi1qnWdpMRIrvlrUjd0/69pObqf8hVC17p/wBe0nN1P+Qqh9FY /QYWYzxOcoAQ+OZpqbBN9qKeWSGaK21D45I3K1zHJG5UVFThRUXaZZnV8s3zrap7wV2/hPAsR7Gx WK7fVup1Zz6fBnBGcwj4X+le1vB0rvlVOdWlKIuRTawMV/4vli+db1PeB/xfLF863qe8EKbo8kv1 TvDWfU8kds9rD0u2DagMVTffLF863qe8FyquWL51vU94dJuiyS/VO8NYckds9rD0u2DaQMWRKrli +db1PeC5VXLF863qe8Ok3QpNfqneGsOSS2O1h6XbBtAGL5VXLF863qe8F0arli+db1PeHSYfyi/V O8NZHJJbHaw9Ltg2cDGdGp5YvnW9T3gI2p5YvnW9T3h0mHsov1TvDWHJLbHaw9Ltg2YDGtCp5Yvn W9T3gaFTyxfOt6nvDtMO5VfqneBHJLbHaw9Ltg2UDG0ZU8r3zrep7wNCp5XvnW9T3hKYcyy/VO8A 5JbY7WHpdsGyAY4kdRyvfOt6nvA8HUcr3zrep7w7TDaWX6t3gHJNbHaw9Ltg2MDHPB1HK9863qe8 F8FUcr3zrep7w6TDOXX6tfAjkmtjtYel2wbEBjvgqjle+db1PeCpFPyvfOt6nvDpMMYC/Vr4ByTW x2sPS7YNhAx/wU/K9863qe8BIp+V751vU94dJhfAX6tdKByT2x2sPS7YNgAyDwM/K1863qu8DwM/ K1863qu8O0wsgr9WulCOSe1+1h6XbBr4GQ+Am5WvnW9V3geAm5WvnW9V3h0mFUJfq10oHJRa/aw9 Ltg14DIkgm5WvnW9V3geAm5WvnXFV
Re: [E-devel] Imlib2 patch
Dariusz Knociński wrote: > Hi All, > I wrote new version of some procedures in Imlib2 library and attached patches > for that > mail. > > In file color-helpres procedures : > > void __imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v ); > void __imlib_hsv_to_rgb( float h, float s, float v, int *r, int *g, int *b > ); > > I have changed the range of parameters hue from 0-100 to 0-360, and > saturation and value > from 0-100 to 0-1. This is correct to last version of documentation on the > web page. > > In file grad.c procedures : > > void __imlib_MapRange( ImlibRange * rg, int len ) > void __imlib_MapHsvaRange( ImlibRange * rg, int len ) > > I have changed internal variable inc > from: > inc = ((ll - 1) << 16) / (len); > to: > inc = ((ll - 1) << 16) / (len-1); > This patch repair bug for small values of parameter len, for example from 2 > to 16. > > And I apply two small screenshots of application imlib2_colorspace befor and > after patch. > The patch applies/compiles cleanly and seems to fix the problem in imlib2_colorspace - haven't checked beyond that. I'll commit this if there are no objections and noone beats me to it :) /Kim - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 patch
Dariusz Knociński wrote:
> Patch:
> diff -u -p -r imlib2-1.4.1.000.old/src/lib/color_helpers.c
> imlib2-1.4.1.000.new/src/lib/color_helpers.c
> --- imlib2-1.4.1.000.old/src/lib/color_helpers.c 2007-05-21
> 00:58:01.0 +0200
> +++ imlib2-1.4.1.000.new/src/lib/color_helpers.c 2008-04-15
> 09:34:36.0 +0200
> @@ -5,117 +5,89 @@
> */
>
> void
> -__imlib_rgb_to_hsv(int r, int g, int b, float *h, float *s, float *v)
> +__imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v )
> {
> - int min, max;
> - int delta;
> + register float min, max, delta;
>
> - max = (r + g + abs(r - g)) / 2;
> - max = (max + b + abs(max - b)) / 2;
> - min = (r + g - abs(r - g)) / 2;
> - min = (min + b - abs(min - b)) / 2;
> +min = ((( r < g ) ? r : g) < b ) ? (( r < g ) ? r : g) : b;
> +max = ((( r > g ) ? r : g) > b ) ? (( r > g ) ? r : g) : b;
>
> - delta = max - min;
> - *v = (float)(100 * max) / 255.0;
> -
> - if (max != 0)
> - *s = (float)(100 * delta) / (float)max;
> - else
> - {
> -*s = 0.0;
> +*v = max / 255.0;
> + delta = ( max - min );
> +if( delta == 0 )
> +{
> *h = 0.0;
> -*v = 0.0;
> - }
> - if (r == max)
> - {
> -*h = (float)(100 * (g - b)) / (float)(6.0 * delta);
> - }
> - else
> - {
> -if (g == max)
> - {
> - *h = (float)(100 * (2 * delta + b - r)) / (float)(6.0 * delta);
> - }
> -else
> - {
> - *h = (float)(100 * (4 * delta + r - g)) / (float)(6.0 * delta);
> - }
> - }
> - if (*h < 0.0)
> - *h += 100.0;
> - if (*h > 100.0)
> - *h -= 100.0;
> +*s = 0.0;
> +return;
> +}
> +*s = delta / max;
> + if( r == max )
> + *h = ( g - b ) / delta;
> + else if( g == max )
> + *h = 2.0 + ( b - r ) / delta;
> + else
> + *h = 4.0 + ( r - g ) / delta;
> + *h *= 60.0;
> + if( *h < 0 )
> + *h += 360.0;
> }
>
> void
> __imlib_hsv_to_rgb(float h, float s, float v, int *r, int *g, int *b)
> {
> - float hh, f;
> - float p, q, t;
> - int i;
> +register float f, vf;
> +register int i, p, q, t, vv;
>
> - if (s == 0.0)
> - {
> -*r = round((v * 255.0) / 100.0);
> -*g = round((v * 255.0) / 100.0);
> -*b = round((v * 255.0) / 100.0);
> +vf = 255.0 * v;
> +vv = (int)round( vf );
>
> +if( s == 0.0 )
> +{
> +*r = *g = *b = vv;
> return;
> - }
> -
> - hh = (h * 6.0) / 100.0;
> - i = floor(hh);
> - f = hh - (float)i;
> -
> - p = v * (1.0 - s / 100.0) / 100.0;
> - q = v * (1.0 - (s * f) / 100.0) / 100.0;
> - t = v * (1.0 - s * (1.0 - f) / 100.0) / 100.0;
> +}
>
> - switch (i)
> - {
> - case 0:
> -{
> - *r = round(v * 255.0 / 100.0);
> - *g = round(t * 255.0);
> - *b = round(p * 255.0);
> - break;
> -}
> - case 1:
> -{
> - *r = round(q * 255.0);
> - *g = round(v * 255.0 / 100.0);
> - *b = round(p * 255.0);
> - break;
> -}
> - case 2:
> -{
> - *r = round(p * 255.0);
> - *g = round(v * 255.0 / 100.0);
> - *b = round(t * 255.0);
> - break;
> -}
> - case 3:
> -{
> - *r = round(p * 255.0);
> - *g = round(q * 255.0);
> - *b = round(v * 255.0 / 100.0);
> - break;
> -}
> - case 4:
> -{
> - *r = round(t * 255.0);
> - *g = round(p * 255.0);
> - *b = round(v * 255.0 / 100.0);
> - break;
> -}
> - case 5:
> -{
> - *r = round(v * 255.0 / 100.0);
> - *g = round(p * 255.0);
> - *b = round(q * 255.0);
> - break;
> -}
> - }
> +h /= 60.0;
> +i = floor(h);
> +f = h - (float)i;
> +p = (int)round( vf * (1.0 - s ));
> +q = (int)round( vf * (1.0 - (s * f)));
> +t = (int)round( vf * (1.0 - s * (1.0 - f)));
> +
> +switch( i % 6 )
> +{
> +case 0:
> +*r = vv;
> +*g = t;
> +*b = p;
> +break;
> +case 1:
> +*r = q;
> +*g = vv;
> +*b = p;
> +break;
> +case 2:
> +*r = p;
> +*g = vv;
> +*b = t;
> +break;
> +case 3:
> +*r = p;
> +*g = q;
> +*b = vv;
> +break;
> +case 4:
> +*r = t;
> +*g = p;
> +*b = vv;
> +break;
> +case 5:
> +default:
> +*r = vv;
> +*g = p;
> +*b = q;
> +break;
> +}
> }
>
> void
> diff -u -p -r imlib2-1.4.1.000.old/src/lib/grad.c
> imlib2-1.4.1.000.new/src/lib/grad.c
> --- imlib2-1.4.1.000.old/src/lib/grad.c 2007-05-21 00:58:0
Re: [E-devel] Imlib2 patch
On Wed, 16 Apr 2008 19:50:24 -0400 Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Dariusz Knociński wrote: [...] > > > > Strictly speaking, this is still incorrect. The reason being > that the map-range functions are doing an initial interpolation in > rgb colorspace. It should be doing all of the interpolation in hsv > color space, not partly in rgb space then the rest in hsv one. > > Yes. I know, function MapHsvaRange working very not efficient, but I have not spare time for corect this, at the current time I think :-) Regards -- Dariusz Knociński - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 patch
Kim Woelders wrote: > Dariusz Knociński wrote: >> Hi All, >> I wrote new version of some procedures in Imlib2 library and attached >> patches for that >> mail. >> >> In file color-helpres procedures : >> >> void __imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v ); >> void __imlib_hsv_to_rgb( float h, float s, float v, int *r, int *g, int >> *b ); >> >> I have changed the range of parameters hue from 0-100 to 0-360, and >> saturation and value >> from 0-100 to 0-1. This is correct to last version of documentation on the >> web page. >> >> In file grad.c procedures : >> >> void __imlib_MapRange( ImlibRange * rg, int len ) >> void __imlib_MapHsvaRange( ImlibRange * rg, int len ) >> >> I have changed internal variable inc >> from: >> inc = ((ll - 1) << 16) / (len); >> to: >> inc = ((ll - 1) << 16) / (len-1); >> This patch repair bug for small values of parameter len, for example from 2 >> to 16. >> >> And I apply two small screenshots of application imlib2_colorspace befor and >> after patch. >> > The patch applies/compiles cleanly and seems to fix the problem in > imlib2_colorspace - haven't checked beyond that. > I'll commit this if there are no objections and noone beats me to it :) > On second thought - This might break stuff that relies on the old behavior. Maybe the documentation should be changed in stead? raster? /Kim - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 patch
Kim Woelders wrote: > Kim Woelders wrote: >> Dariusz Knociński wrote: >>> Hi All, >>> I wrote new version of some procedures in Imlib2 library and attached >>> patches for that >>> mail. >>> >>> In file color-helpres procedures : >>> >>> void __imlib_rgb_to_hsv( int r, int g, int b, float *h, float *s, float *v >>> ); >>> void __imlib_hsv_to_rgb( float h, float s, float v, int *r, int *g, int >>> *b ); >>> >>> I have changed the range of parameters hue from 0-100 to 0-360, and >>> saturation and value >>> from 0-100 to 0-1. This is correct to last version of documentation on the >>> web page. >>> >>> In file grad.c procedures : >>> >>> void __imlib_MapRange( ImlibRange * rg, int len ) >>> void __imlib_MapHsvaRange( ImlibRange * rg, int len ) >>> >>> I have changed internal variable inc >>> from: >>> inc = ((ll - 1) << 16) / (len); >>> to: >>> inc = ((ll - 1) << 16) / (len-1); >>> This patch repair bug for small values of parameter len, for example from 2 >>> to 16. >>> >>> And I apply two small screenshots of application imlib2_colorspace befor >>> and after patch. >>> >> The patch applies/compiles cleanly and seems to fix the problem in >> imlib2_colorspace - haven't checked beyond that. >> I'll commit this if there are no objections and noone beats me to it :) >> > On second thought - This might break stuff that relies on the old > behavior. Maybe the documentation should be changed in stead? > > raster? > Ok'ed by raster - committed. You are of course welcome to address correctness/speed issues :) I have corrected formatting and removed use of the register keyword, as it doesn't make sense to me to use it here when it isn't used anywhere else in imlib2 and I doubt it has any impact on performance (in this case, anyway). /Kim - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [imlib2][PATCH] loader_gif: fix OOB read
As reported on http://bugs.debian.org/734425, when ColorCount is less
than 256, it is possible that image loading will trigger out of bound
read.
Security imlications: DoS (application crash), potentially host memory
exposure.
Attached patch(es) gracefully handles out-of-range image data, out-of-range
background and transparent colors, and make code a bit simplier and
faster.
Description: Fixes out-of-bound reads from colormap
Bug-Debian: http://bugs.debian.org/734425
Note: removes all special-casing from the inner loop, optimize for common case.
Author: Yuriy M. Kaminskiy
Reported-By: Jakub Wilk
Thanks to Bernhard U:belacker for analysis.
Index: imlib2-1.4.7/src/modules/loaders/loader_gif.c
===
--- imlib2-1.4.7.orig/src/modules/loaders/loader_gif.c
+++ imlib2-1.4.7/src/modules/loaders/loader_gif.c
@@ -141,8 +141,24 @@ load(ImlibImage * im, ImlibProgressFunct
if (im->loader || immediate_load || progress)
{
+DATA32 colormap[256];
+
bg = gif->SBackGroundColor;
cmap = (gif->Image.ColorMap ? gif->Image.ColorMap : gif->SColorMap);
+memset (colormap, 0, sizeof(colormap));
+if (cmap != NULL)
+ {
+ for (i = cmap->ColorCount > 256 ? 256 : cmap->ColorCount; i-- > 0;)
+ {
+r = cmap->Colors[i].Red;
+g = cmap->Colors[i].Green;
+b = cmap->Colors[i].Blue;
+colormap[i] = (0xff << 24) | (r << 16) | (g << 8) | b;
+ }
+ /* if bg > cmap->ColorCount, it is transparent black already */
+ if (transp >= 0 && transp < 256)
+ colormap[transp] = bg >= 0 && bg < 256 ? colormap[bg] & 0x00ff : 0x;
+ }
im->data = (DATA32 *) malloc(sizeof(DATA32) * w * h);
if (!im->data)
goto quit;
@@ -161,20 +177,7 @@ load(ImlibImage * im, ImlibProgressFunct
{
for (j = 0; j < w; j++)
{
- if (rows[i][j] == transp)
-{
- r = cmap->Colors[bg].Red;
- g = cmap->Colors[bg].Green;
- b = cmap->Colors[bg].Blue;
- *ptr++ = 0x00ff & ((r << 16) | (g << 8) | b);
-}
- else
-{
- r = cmap->Colors[rows[i][j]].Red;
- g = cmap->Colors[rows[i][j]].Green;
- b = cmap->Colors[rows[i][j]].Blue;
- *ptr++ = (0xff << 24) | (r << 16) | (g << 8) | b;
-}
+ *ptr++ = colormap[rows[i][j]];
per += per_inc;
if (progress && (((int)per) != last_per)
&& (((int)per) % progress_granularity == 0))
Description: cleanup: remove check redundant by fix-bug-785369.patch
Index: imlib2-1.4.7/src/modules/loaders/loader_gif.c
===
--- imlib2-1.4.7.orig/src/modules/loaders/loader_gif.c
+++ imlib2-1.4.7/src/modules/loaders/loader_gif.c
@@ -163,14 +163,6 @@ load(ImlibImage * im, ImlibProgressFunct
if (!im->data)
goto quit;
-if (!cmap)
- {
- /* No colormap? Now what?? Let's clear the image (and not segv) */
- memset(im->data, 0, sizeof(DATA32) * w * h);
- rc = 1;
- goto finish;
- }
-
ptr = im->data;
per_inc = 100.0 / (((float)w) * h);
for (i = 0; i < h; i++)
Description: reduce progress checks from per-pixel to per-row
Index: imlib2-1.4.7/src/modules/loaders/loader_gif.c
===
--- imlib2-1.4.7.orig/src/modules/loaders/loader_gif.c
+++ imlib2-1.4.7/src/modules/loaders/loader_gif.c
@@ -164,12 +164,13 @@ load(ImlibImage * im, ImlibProgressFunct
goto quit;
ptr = im->data;
-per_inc = 100.0 / (((float)w) * h);
+per_inc = 100.0 / (float)h;
for (i = 0; i < h; i++)
{
for (j = 0; j < w; j++)
{
*ptr++ = colormap[rows[i][j]];
+ }
per += per_inc;
if (progress && (((int)per) != last_per)
&& (((int)per) % progress_granularity == 0))
@@ -182,7 +183,6 @@ load(ImlibImage * im, ImlibProgressFunct
}
last_y = i;
}
- }
}
finish:
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140___
[E-devel] imlib2 patch, configure.in X header detection
Stuff broke with the X header detection in imlib2's configure script. (See http://bugs.debian.org/295350 for details.) Steven Langasek provided a patch. --- imlib2-1.2.0.orig/configure.in +++ imlib2-1.2.0/configure.in @@ -139,35 +139,28 @@ freetype_cflags=`$FREETYPE_CONFIG --cflags` freetype_libs=`$FREETYPE_CONFIG --libs` -x11=no -AC_ARG_ENABLE(x11,[ --disable-x11 attempt to build with X11 support [default=yes]], -[ - if test x$enableval = xyes; then -have_x=yes - else -have_x=no - fi -], -[ - AC_CHECK_HEADER(X11/X.h, -[ have_x="yes" ], -[ have_x="no" ] - ) -] -) -AC_MSG_CHECKING(whether X11 support is to be enabled) +AC_PATH_X([X], [X11/Xlib.h], [XOpenDisplay(NULL)]) + +if test "x$have_x" = "xno"; then + # If --without-x was passed, this will be "disabled" instead of "no" -- + # so always treat "no" as an error + AC_MSG_ERROR( +[no X support found. Use --x-includes and --x-libraries to specify the X +path on your system, or --without-x to disable X support.]) +fi + if test "x$have_x" = "xyes"; then - x_dir="/usr/X11R6"; - x_cflags="-I"$x_dir"/include" - x_libs="-L"$x_dir"/lib -lX11 -lXext" - AC_MSG_RESULT(enabling X11 support) + if test "x$x_includes" != "x"; then +x_cflags="-I$x_includes" + fi + if test "x$x_libraries" != "x"; then +x_libs="-L$x_libraries -lX11 -lXext" + fi AM_CONDITIONAL(BUILD_X11, true) AC_DEFINE(BUILD_X11, 1, [enabling X11 support]) else - x_dir="" x_cflags="" x_libs="" - AC_MSG_RESULT(disabling X11 support) AM_CONDITIONAL(BUILD_X11, false) fi --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [imlib2][PATCH] loader_gif: fix OOB read
On Sat, 02 Apr 2016 04:49:08 +0300 yum...@gmail.com (Yuriy M. Kaminskiy) said: > As reported on http://bugs.debian.org/734425, when ColorCount is less > than 256, it is possible that image loading will trigger out of bound > read. > Security imlications: DoS (application crash), potentially host memory > exposure. > Attached patch(es) gracefully handles out-of-range image data, out-of-range > background and transparent colors, and make code a bit simplier and > faster. ummm can you explain how this actually CAN happen? and the debian bugzilla entry you point it is just discussing patches to imlib2-config etc. - not this patch or security issues that i can see... so red herring? wrong link? so i and j are defined by code so are always >= 0. rows[i][j] does a fetch of pixel value at that row i and x position (j) and this is with giflib headers an unsigned char. so it can never be < 0. bg comes from SBackGroundColor which is an int in giflib api, but if you check the gif format specs, the background color index is a byte - and it's obviously an unsigned byte otherwise indexes >= 128 would be impossible to access... now ColorCount ... how can this be > 256 or < 0? gifg specs allocate 3 bits to color table size. this defines the numebr of BITS for the color table, so can contain values 0 to 7 or mapping really to # of buts being 1 to 8 bitss for color table. so 2, 4, 8, 16, 32, 64, 128 or 256. this colorcount should never be < 2 or > 256 by specifications of the file format and giflib handling of it. are you saying giflib has bugs where it sometimes provides junk for the bg color or colorcount since the c type allows values outside the range? give the actual file format itself there simply is no space in the format to create an exploit. at least not what i'm reading from your patch and from giflib headers and from gif file format specs. so if there is an issue that i am not looking at - can you point it out? this almost smells of someone having uses static analysis tools finding variables that allow negatives (ints) where usage only uses a subset (0 to 255 or 2 to 256) and going "ooh bug bug bug bug! security issue" and not digging a little deeper. :) if this is the case - bravo on actually using tools and doing this. these are possible bug vectors, but given all the other constraints, this is not an issue. you'd be RIGHT if a gif format file used an int for the colorcount and the parser didn't specifically check ranges (giflib would be the place to put this). :) see: https://www.w3.org/Graphics/GIF/spec-gif89a.txt http://giflib.sourceforge.net/gif_lib.html http://giflib.sourceforge.net/gif_lib.html -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [imlib2][PATCH] loader_gif: fix OOB read
On Sat, 02 Apr 2016 04:49:08 +0300 yum...@gmail.com (Yuriy M. Kaminskiy) said: > As reported on http://bugs.debian.org/734425, when ColorCount is less > than 256, it is possible that image loading will trigger out of bound > read. > Security imlications: DoS (application crash), potentially host memory > exposure. > Attached patch(es) gracefully handles out-of-range image data, out-of-range > background and transparent colors, and make code a bit simplier and > faster. oh wait... i wass reading the patch looking for < 0 .. sorry < 256 but intex values can be greater. (up to 255) eg colormap is 32 entriess but you have pixels with > 31 value. btw the debian bug you link to is not disscussing that - imlib2 config thing. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [imlib2][PATCH] loader_gif: fix OOB read
On Sat, 2 Apr 2016 06:48:54 +0300 "Yuriy M. Kaminskiy" said: > On 02.04.2016 06:21, Yuriy M. Kaminskiy wrote: > > On 02.04.2016 06:12, Carsten Haitzler (The Rasterman) wrote: > >> On Sat, 02 Apr 2016 04:49:08 +0300 yum...@gmail.com (Yuriy M. > >> Kaminskiy) said: > >> > >>> As reported on http://bugs.debian.org/734425, when ColorCount is less > >>> than 256, it is possible that image loading will trigger out of bound > >>> read. > >>> Security imlications: DoS (application crash), potentially host memory > >>> exposure. > >>> Attached patch(es) gracefully handles out-of-range image data, > >>> out-of-range > >>> background and transparent colors, and make code a bit simplier and > >>> faster. > >> ummm can you explain how this actually CAN happen? > >> > >> and the debian bugzilla entry you point it is just discussing > >> patches to > >> imlib2-config etc. - not this patch or security issues that i can > >> see... so red > >> herring? wrong link? > > Sorry, bug link is wrong. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785369 > > > >> > >> so i and j are defined by code so are always >= 0. > > > > It is not about i and j. It is about row[i][j]. Which might be more > > than ColorCount, and *not* verified by giflib. Same applies to > > SBackGroundColor, it can also trigger out-of-bound reads from cmap. > > Checks for more than 256 and less than 0 is pure paranoia, but won't > > harm anyway. > (... except for `transp`, which *can* be -1, legitimately [and that case > was *not* broken in current code]). see my other reply - i was looking at < 0 cases or for color values to be beyond 255 etc. as the patch removed a lot of the pixel lookups. it was the <= 255 > max palette index gap. small and just a dos but i wanted to know the core issue because ... i actually don't care about imlib2 :) that has been dropped from my radar like back in 2003/4 or so... :) but evas has a gif loader and it does suffer the same issue. i just fixed it and pushed a patch. but i'm alsso distracted by giflib seemingly behaving erratically. i think. like an image (gif image) had parse errors if you load it off the bat - run the app for a while then load and it loads FINE later... giflib itself is complaining of gif errors in the file decode... it seems.. i think i may have hit on a libgif issue - buty i am not sure. i am certain our gif loader worked fine the last time i heavily checked it and it hasnt changed in years really... so why would it fail now? something else is up. > [...] > >> so if there is an issue that i am not looking at - can you point it > >> out? this > >> almost smells of someone having uses static analysis tools finding > >> variables > > No, it is the case someone (not me, fwiw) using valgrind to detect how > libraries handles fuzzied files, and found real bugs. > > >> that allow negatives (ints) where usage only uses a subset (0 to 255 > >> or 2 to > >> 256) and going "ooh bug bug bug bug! security issue" and not digging > >> a little > >> deeper. :) if this is the case - bravo on actually using tools and > >> doing this. > >> these are possible bug vectors, but given all the other constraints, > >> this is > >> not an issue. you'd be RIGHT if a gif format file used an int for the > >> colorcount and the parser didn't specifically check ranges (giflib > >> would be the > >> place to put this). :) > >> > >> see: > >> > >> https://www.w3.org/Graphics/GIF/spec-gif89a.txt > >> http://giflib.sourceforge.net/gif_lib.html > >> http://giflib.sourceforge.net/gif_lib.html > >> > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [imlib2][PATCH] loader_gif: fix OOB read
On Sat, 2 Apr 2016 13:39:53 +0900 Carsten Haitzler (The Rasterman) said: > On Sat, 2 Apr 2016 06:48:54 +0300 "Yuriy M. Kaminskiy" > said: > > > On 02.04.2016 06:21, Yuriy M. Kaminskiy wrote: > > > On 02.04.2016 06:12, Carsten Haitzler (The Rasterman) wrote: > > >> On Sat, 02 Apr 2016 04:49:08 +0300 yum...@gmail.com (Yuriy M. > > >> Kaminskiy) said: > > >> > > >>> As reported on http://bugs.debian.org/734425, when ColorCount is less > > >>> than 256, it is possible that image loading will trigger out of bound > > >>> read. > > >>> Security imlications: DoS (application crash), potentially host memory > > >>> exposure. > > >>> Attached patch(es) gracefully handles out-of-range image data, > > >>> out-of-range > > >>> background and transparent colors, and make code a bit simplier and > > >>> faster. > > >> ummm can you explain how this actually CAN happen? > > >> > > >> and the debian bugzilla entry you point it is just discussing > > >> patches to > > >> imlib2-config etc. - not this patch or security issues that i can > > >> see... so red > > >> herring? wrong link? > > > Sorry, bug link is wrong. > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785369 > > > > > >> > > >> so i and j are defined by code so are always >= 0. > > > > > > It is not about i and j. It is about row[i][j]. Which might be more > > > than ColorCount, and *not* verified by giflib. Same applies to > > > SBackGroundColor, it can also trigger out-of-bound reads from cmap. > > > Checks for more than 256 and less than 0 is pure paranoia, but won't > > > harm anyway. > > (... except for `transp`, which *can* be -1, legitimately [and that case > > was *not* broken in current code]). > > see my other reply - i was looking at < 0 cases or for color values to be > beyond 255 etc. as the patch removed a lot of the pixel lookups. it was the <= > 255 > max palette index gap. small and just a dos but > > i wanted to know the core issue because ... i actually don't care about > imlib2 :) that has been dropped from my radar like back in 2003/4 or so... :) > but evas has a gif loader and it does suffer the same issue. i just fixed it > and pushed a patch. > > but i'm alsso distracted by giflib seemingly behaving erratically. i think. > like an image (gif image) had parse errors if you load it off the bat - run > the app for a while then load and it loads FINE later... giflib itself is > complaining of gif errors in the file decode... it seems.. i think i may have > hit on a libgif issue - buty i am not sure. i am certain our gif loader worked > fine the last time i heavily checked it and it hasnt changed in years > really... so why would it fail now? something else is up. yup. giflib 5 bug. found. fixed (or at least reported with patch fix). :) https://sourceforge.net/p/giflib/bugs/94/ > > [...] > > >> so if there is an issue that i am not looking at - can you point it > > >> out? this > > >> almost smells of someone having uses static analysis tools finding > > >> variables > > > > No, it is the case someone (not me, fwiw) using valgrind to detect how > > libraries handles fuzzied files, and found real bugs. > > > > >> that allow negatives (ints) where usage only uses a subset (0 to 255 > > >> or 2 to > > >> 256) and going "ooh bug bug bug bug! security issue" and not digging > > >> a little > > >> deeper. :) if this is the case - bravo on actually using tools and > > >> doing this. > > >> these are possible bug vectors, but given all the other constraints, > > >> this is > > >> not an issue. you'd be RIGHT if a gif format file used an int for the > > >> colorcount and the parser didn't specifically check ranges (giflib > > >> would be the > > >> place to put this). :) > > >> > > >> see: > > >> > > >> https://www.w3.org/Graphics/GIF/spec-gif89a.txt > > >> http://giflib.sourceforge.net/gif_lib.html > > >> http://giflib.sourceforge.net/gif_lib.html > > >> > > > > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > -- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278
Re: [E-devel] imlib2 patch, configure.in X header detection
On Thu, 17 Feb 2005 20:36:20 -0600 "Laurence J. Lane" <[EMAIL PROTECTED]> (Bbabbled: (B (B> Stuff broke with the X header detection in imlib2's (B> configure script. (See http://bugs.debian.org/295350 (B> for details.) (B (Bthanks for the info :) fixed :) (B (B> Steven Langasek provided a patch. (B> (B> (B> --- imlib2-1.2.0.orig/configure.in (B> +++ imlib2-1.2.0/configure.in (B> @@ -139,35 +139,28 @@ (B> freetype_cflags=`$FREETYPE_CONFIG --cflags` (B> freetype_libs=`$FREETYPE_CONFIG --libs` (B> (B> -x11=no (B> -AC_ARG_ENABLE(x11,[ --disable-x11 attempt to build with X11 (Bsupport [default=yes]], (B> -[ (B> - if test x$enableval = xyes; then (B> -have_x=yes (B> - else (B> -have_x=no (B> - fi (B> -], (B> -[ (B> - AC_CHECK_HEADER(X11/X.h, (B> -[ have_x="yes" ], (B> -[ have_x="no" ] (B> - ) (B> -] (B> -) (B> -AC_MSG_CHECKING(whether X11 support is to be enabled) (B> +AC_PATH_X([X], [X11/Xlib.h], [XOpenDisplay(NULL)]) (B> + (B> +if test "x$have_x" = "xno"; then (B> + # If --without-x was passed, this will be "disabled" instead of "no" -- (B> + # so always treat "no" as an error (B> + AC_MSG_ERROR( (B> +[no X support found. Use --x-includes and --x-libraries to specify the X (B> +path on your system, or --without-x to disable X support.]) (B> +fi (B> + (B> if test "x$have_x" = "xyes"; then (B> - x_dir="/usr/X11R6"; (B> - x_cflags="-I"$x_dir"/include" (B> - x_libs="-L"$x_dir"/lib -lX11 -lXext" (B> - AC_MSG_RESULT(enabling X11 support) (B> + if test "x$x_includes" != "x"; then (B> +x_cflags="-I$x_includes" (B> + fi (B> + if test "x$x_libraries" != "x"; then (B> +x_libs="-L$x_libraries -lX11 -lXext" (B> + fi (B>AM_CONDITIONAL(BUILD_X11, true) (B>AC_DEFINE(BUILD_X11, 1, [enabling X11 support]) (B> else (B> - x_dir="" (B>x_cflags="" (B>x_libs="" (B> - AC_MSG_RESULT(disabling X11 support) (B>AM_CONDITIONAL(BUILD_X11, false) (B> fi (B> (B> (B> (B> --- (B> SF email is sponsored by - The IT Product Guide (B> Read honest & candid reviews on hundreds of IT Products from real users. (B> Discover which products truly live up to the hype. Start reading now. (B> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click (B> ___ (B> enlightenment-devel mailing list (B> enlightenment-devel@lists.sourceforge.net (B> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel (B> (B (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $BMg9%B?(B [EMAIL PROTECTED] (BTokyo, Japan ($BEl5~(B $BF|K\(B) (B (B (B--- (BSF email is sponsored by - The IT Product Guide (BRead honest & candid reviews on hundreds of IT Products from real users. (BDiscover which products truly live up to the hype. Start reading now. (Bhttp://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click (B___ (Benlightenment-devel mailing list (Benlightenment-devel@lists.sourceforge.net (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Imlib2 PATCH: Check for rgb.txt in /ust/share/X11
Hi,
Short intro: I'm the Fedora imlib2 package maintainer.
Most modern Linux distro's now have rgb.txt as
/ust/share/X11/rgb.txt
The attached patch fixes loading xpm files on these distro's.
Regards,
Hans
p.s.
Please keep me CC-ed, I'm not on the list.
diff -up imlib2-1.4.1/src/modules/loaders/loader_xpm.c~
imlib2-1.4.1/src/modules/loaders/loader_xpm.c
--- imlib2-1.4.1/src/modules/loaders/loader_xpm.c~ 2008-06-12
20:45:41.0 +0200
+++ imlib2-1.4.1/src/modules/loaders/loader_xpm.c 2008-06-12
20:45:41.0 +0200
@@ -52,6 +52,8 @@ xpm_parse_color(char *color, int *r, int
/* look in rgb txt database */
if (!rgb_txt)
#ifndef __EMX__
+ rgb_txt = fopen("/usr/share/X11/rgb.txt", "r");
+ if (!rgb_txt)
rgb_txt = fopen("/usr/X11R6/lib/X11/rgb.txt", "r");
if (!rgb_txt)
rgb_txt = fopen("/usr/openwin/lib/X11/rgb.txt", "r");
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Imlib2: Patch: add various checks to various image loaders
Hi,
Short intro: I'm the Fedora imlib2 package maintainer.
Some time ago there was a bunch of security advisories for various imlib2 image
loaders. Some of the fixes which were circulating then never seem to have been
applied to imlib2, the attached patch includes these fixes.
Regards,
Hans
p.s.
Please keep me CC-ed, I'm not on the list.
diff -Nur imlib2-1.2.1/src/modules/loaders/loader_argb.c
imlib2-1.2.1.new/src/modules/loaders/loader_argb.c
--- imlib2-1.2.1/src/modules/loaders/loader_argb.c 2006-11-06
01:27:59.0 -0800
+++ imlib2-1.2.1.new/src/modules/loaders/loader_argb.c 2006-11-06
01:30:41.0 -0800
@@ -23,7 +23,7 @@
load(ImlibImage * im, ImlibProgressFunction progress,
char progress_granularity, char immediate_load)
{
- int w, h, alpha;
+ int w=0, h=0, alpha=0;
FILE *f;
if (im->data)
@@ -36,6 +36,8 @@
{
charbuf[256], buf2[256];
+ memset(buf, 0, sizeof(buf));
+ memset(buf2, 0, sizeof(buf));
if (!fgets(buf, 255, f))
{
fclose(f);
diff -Nur imlib2-1.2.1/src/modules/loaders/loader_jpeg.c
imlib2-1.2.1.new/src/modules/loaders/loader_jpeg.c
--- imlib2-1.2.1/src/modules/loaders/loader_jpeg.c 2006-11-06
01:27:59.0 -0800
+++ imlib2-1.2.1.new/src/modules/loaders/loader_jpeg.c 2006-11-06
01:33:01.0 -0800
@@ -104,8 +104,9 @@
im->w = w = cinfo.output_width;
im->h = h = cinfo.output_height;
-if (cinfo.rec_outbuf_height > 16)
+if (cinfo.rec_outbuf_height > 16 || w < 1 || h < 1 || w > 16383 || h >
16383)
{
+im->w = im->h = 0;
jpeg_destroy_decompress(&cinfo);
fclose(f);
return 0;
diff -Nur imlib2-1.2.1/src/modules/loaders/loader_lbm.c
imlib2-1.2.1.new/src/modules/loaders/loader_lbm.c
--- imlib2-1.2.1/src/modules/loaders/loader_lbm.c 2006-11-06
01:27:59.0 -0800
+++ imlib2-1.2.1.new/src/modules/loaders/loader_lbm.c 2006-11-06
01:30:41.0 -0800
@@ -453,6 +453,7 @@
}
}
if (!full || !ok) {
+im->w = im->h = 0;
freeilbm(&ilbm);
return ok;
}
@@ -467,12 +468,13 @@
cancel = 0;
plane[0] = NULL;
+n = ilbm.depth;
+if (ilbm.mask == 1) n++;
+
im->data = malloc(im->w * im->h * sizeof(DATA32));
-if (im->data) {
-n = ilbm.depth;
-if (ilbm.mask == 1) n++;
+plane[0] = malloc(((im->w + 15) / 16) * 2 * n);
+if (im->data && plane[0]) {
-plane[0] = malloc(((im->w + 15) / 16) * 2 * n);
for (i = 1; i < n; i++) plane[i] = plane[i - 1] + ((im->w + 15) / 16)
* 2;
z = ((im->w + 15) / 16) * 2 * n;
@@ -511,6 +513,7 @@
* the memory for im->data.
*--*/
if (!ok) {
+im->w = im->h = 0;
if (im->data) free(im->data);
im->data = NULL;
}
diff -Nur imlib2-1.2.1/src/modules/loaders/loader_tga.c
imlib2-1.2.1.new/src/modules/loaders/loader_tga.c
--- imlib2-1.2.1/src/modules/loaders/loader_tga.c 2006-11-06
01:27:59.0 -0800
+++ imlib2-1.2.1.new/src/modules/loaders/loader_tga.c 2006-11-06
01:30:41.0 -0800
@@ -365,7 +369,9 @@
else
dataptr = im->data + (y * im->w);
- for (x = 0; x < im->w; x++) /* for each pixel in the row */
+ for (x = 0;
+ x < im->w && bufptr+bpp/8 < bufend;
+ x++) /* for each pixel in the row */
{
switch (bpp)
{
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [imlib2] [PATCH] off-by-one OOB read in __imlib_MergeUpdate
Run `valgrind imlib2_test`, move mouse to right lower corner, got
==16086== Invalid read of size 1
==16086==at 0x4E79C4E: __imlib_MergeUpdate (in
/usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)
==16086==by 0x401773: main (in /usr/bin/imlib2_test)
==16086== Address 0x9d20360 is 0 bytes after a block of size 1,200
alloc'd
==16086==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16086==by 0x4E798E3: __imlib_MergeUpdate (in
/usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)
==16086==by 0x401773: main (in /usr/bin/imlib2_test)
It is at src/lib/updates.c:
|113| for (xx = x + 1, ww = 1;
|
>|114|(T(xx, y).used & T_USED) && (xx < tw);
xx++,|
|115| for (yy = y + 1, hh = 1, ok = 1;
|
xx is 20 and tw is 20, so T(xx, y) addresses one byte out of buffer.
Two *alternative* patches attached (apply only *one* of them).
TODO: I have not tried to search for similar pattern over codebase (yet).
Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818
Description: off-by-one out-of-bound read due to reversed condtion
Author: Yuriy M. Kaminksiy
Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818
Note: you need *either* off-by-one-alternative.patch, *or* this patch;
DO NOT APPLY BOTH! (it won't break, but would unnecessarily clutter code)
Index: imlib2-1.4.6/src/lib/updates.c
===
--- imlib2-1.4.6.orig/src/lib/updates.c
+++ imlib2-1.4.6/src/lib/updates.c
@@ -111,7 +111,7 @@ __imlib_MergeUpdate(ImlibUpdate * u, int
int xx, yy, ww, hh, ok;
for (xx = x + 1, ww = 1;
- (T(xx, y).used & T_USED) && (xx < tw); xx++, ww++);
+ (xx < tw) && (T(xx, y).used & T_USED); xx++, ww++);
for (yy = y + 1, hh = 1, ok = 1;
(yy < th) && (ok); yy++, hh++)
{
Description: off-by-one out-of-bound read due to reversed condtion, alternative solution (allocates one more guard cell).
Author: Yuriy M. Kaminksiy
Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818
Note: you need *either* off-by-one-reversed-condition.patch, *or* this patch;
DO NOT APPLY BOTH! (it won't break, but would unnecessarily clutter code)
Index: imlib2-1.4.6/src/lib/updates.c
===
--- imlib2-1.4.6.orig/src/lib/updates.c
+++ imlib2-1.4.6/src/lib/updates.c
@@ -34,13 +34,14 @@ __imlib_MergeUpdate(ImlibUpdate * u, int
th = h >> TB;
if (h & TM)
th++;
- t = malloc(tw * th * sizeof(struct _tile));
+ t = malloc((tw * th + 1) * sizeof(struct _tile));
/* fill in tiles to be all not used */
for (i = 0, y = 0; y < th; y++)
{
for (x = 0; x < tw; x++)
t[i++].used = T_UNUSED;
}
+ t[i].used = T_UNUSED;
/* fill in all tiles */
for (uu = u; uu; uu = uu->next)
{
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2 PATCH: Check for rgb.txt in /ust/share/X11
On Thursday 12 June 2008, Hans de Goede wrote: > Most modern Linux distro's now have rgb.txt as > /ust/share/X11/rgb.txt > > The attached patch fixes loading xpm files on these distro's. thanks, added to cvs -mike signature.asc Description: This is a digitally signed message part. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2: Patch: add various checks to various image loaders
On Thursday 12 June 2008, Hans de Goede wrote: > Some time ago there was a bunch of security advisories for various imlib2 > image loaders. Some of the fixes which were circulating then never seem to > have been applied to imlib2, the attached patch includes these fixes. i'm pretty sure these were posted & rejected and things were fixed another way -mike signature.asc Description: This is a digitally signed message part. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2: Patch: add various checks to various image loaders
Mike Frysinger wrote: > On Thursday 12 June 2008, Hans de Goede wrote: >> Some time ago there was a bunch of security advisories for various imlib2 >> image loaders. Some of the fixes which were circulating then never seem to >> have been applied to imlib2, the attached patch includes these fixes. > > i'm pretty sure these were posted & rejected and things were fixed another way > -mike It would be prudent to check again, I've been carying this patch for some time (should have submitted it earlier, sorry) and one of the 2 security issues that were fixed in 1.4.1, was already fixed in the Fedora packages through this patch (I removed this part of the patch before sumitting it). Regards, Hans - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2: Patch: add various checks to various image loaders
On Saturday 14 June 2008, Hans de Goede wrote: > Mike Frysinger wrote: > > On Thursday 12 June 2008, Hans de Goede wrote: > >> Some time ago there was a bunch of security advisories for various > >> imlib2 image loaders. Some of the fixes which were circulating then > >> never seem to have been applied to imlib2, the attached patch includes > >> these fixes. > > > > i'm pretty sure these were posted & rejected and things were fixed > > another way > > It would be prudent to check again, I've been carying this patch for > some time (should have submitted it earlier, sorry) and one of the 2 > security issues that were fixed in 1.4.1, was already fixed in the > Fedora packages through this patch (I removed this part of the patch > before sumitting it). you'd have to document/elaborate on what each change fixes exactly -mike signature.asc Description: This is a digitally signed message part. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2: Patch: add various checks to various image loaders
Mike Frysinger wrote: > On Saturday 14 June 2008, Hans de Goede wrote: >> Mike Frysinger wrote: >>> On Thursday 12 June 2008, Hans de Goede wrote: Some time ago there was a bunch of security advisories for various imlib2 image loaders. Some of the fixes which were circulating then never seem to have been applied to imlib2, the attached patch includes these fixes. >>> i'm pretty sure these were posted & rejected and things were fixed >>> another way >> It would be prudent to check again, I've been carying this patch for >> some time (should have submitted it earlier, sorry) and one of the 2 >> security issues that were fixed in 1.4.1, was already fixed in the >> Fedora packages through this patch (I removed this part of the patch >> before sumitting it). > > you'd have to document/elaborate on what each change fixes exactly I didn't write those patches, as you said you've already seen them, they are the result from a previous audit of imlibs loaders. You claim all issues from thisn patch set have been fixed, I content that as one of the 2 security issues fixed in the latest imlib2 release was already fixed in this patch set, see: http://cvs.fedoraproject.org/viewcvs/rpms/imlib2/F-9/imlib2-1.3.0-loader_overflows.patch?rev=1.2 Which is this patch against 1.4.0 and notice how it already has the pnm issues fixed. So there might be merit in the other parts too. Regards, Hans - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Imlib2: Patch: add various checks to various image loaders
Hans de Goede wrote: > Mike Frysinger wrote: >> On Saturday 14 June 2008, Hans de Goede wrote: >>> Mike Frysinger wrote: On Thursday 12 June 2008, Hans de Goede wrote: > Some time ago there was a bunch of security advisories for various > imlib2 image loaders. Some of the fixes which were circulating then > never seem to have been applied to imlib2, the attached patch includes > these fixes. i'm pretty sure these were posted & rejected and things were fixed another way >>> It would be prudent to check again, I've been carying this patch for >>> some time (should have submitted it earlier, sorry) and one of the 2 >>> security issues that were fixed in 1.4.1, was already fixed in the >>> Fedora packages through this patch (I removed this part of the patch >>> before sumitting it). >> you'd have to document/elaborate on what each change fixes exactly > > I didn't write those patches, as you said you've already seen them, they are > the result from a previous audit of imlibs loaders. You claim all issues from > thisn patch set have been fixed, I content that as one of the 2 security > issues > fixed in the latest imlib2 release was already fixed in this patch set, see: > http://cvs.fedoraproject.org/viewcvs/rpms/imlib2/F-9/imlib2-1.3.0-loader_overflows.patch?rev=1.2 > > Which is this patch against 1.4.0 and notice how it already has the pnm > issues > fixed. So there might be merit in the other parts too. > I think this is now taken care of. /Kim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [imlib2] [PATCH] off-by-one OOB read in __imlib_MergeUpdate
On 04/02/2016 08:37 PM, Yuriy M. Kaminskiy wrote: > Run `valgrind imlib2_test`, move mouse to right lower corner, got > ==16086== Invalid read of size 1 > ==16086==at 0x4E79C4E: __imlib_MergeUpdate (in > /usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6) > ==16086==by 0x401773: main (in /usr/bin/imlib2_test) > ==16086== Address 0x9d20360 is 0 bytes after a block of size 1,200 > alloc'd > ==16086==at 0x4C28C20: malloc (vg_replace_malloc.c:296) > ==16086==by 0x4E798E3: __imlib_MergeUpdate (in > /usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6) > ==16086==by 0x401773: main (in /usr/bin/imlib2_test) > > It is at src/lib/updates.c: > |113| for (xx = x + 1, ww = 1; >| >>|114|(T(xx, y).used & T_USED) && (xx < tw); > xx++,| > |115| for (yy = y + 1, hh = 1, ok = 1; >| > > xx is 20 and tw is 20, so T(xx, y) addresses one byte out of buffer. > > Two *alternative* patches attached (apply only *one* of them). > TODO: I have not tried to search for similar pattern over codebase (yet). > > Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818 > > First patch (reversed condition) looks good to me - committed. Thanks :) /Kim -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [imlib2] [PATCH] off-by-one OOB read in __imlib_MergeUpdate
On 04/06/2016 10:44 AM, Kim Woelders wrote: > On 04/02/2016 08:37 PM, Yuriy M. Kaminskiy wrote: >> Run `valgrind imlib2_test`, move mouse to right lower corner, got >> ==16086== Invalid read of size 1 >> ==16086==at 0x4E79C4E: __imlib_MergeUpdate (in >> /usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6) >> ==16086==by 0x401773: main (in /usr/bin/imlib2_test) >> ==16086== Address 0x9d20360 is 0 bytes after a block of size 1,200 >> alloc'd >> ==16086==at 0x4C28C20: malloc (vg_replace_malloc.c:296) >> ==16086==by 0x4E798E3: __imlib_MergeUpdate (in >> /usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6) >> ==16086==by 0x401773: main (in /usr/bin/imlib2_test) >> >> It is at src/lib/updates.c: >> |113| for (xx = x + 1, ww = 1; >> | >>>|114|(T(xx, y).used & T_USED) && (xx < tw); >> xx++,| >> |115| for (yy = y + 1, hh = 1, ok = 1; >> | >> >> xx is 20 and tw is 20, so T(xx, y) addresses one byte out of buffer. >> >> Two *alternative* patches attached (apply only *one* of them). >> TODO: I have not tried to search for similar pattern over codebase (yet). >> >> Debian-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819818 >> >> > First patch (reversed condition) looks good to me - committed. > > Thanks :) > > /Kim > > > > -- > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > Someone decided to assign this CVE-2016-3993 -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE LinuxAdeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
