Activity for Petr Gajdos
-
Petr Gajdos created ticket #766
CVE-2026-33535
-
Thanks!
-
Eh yes, the main part of the patch seems to be in MNG code, or at least this CVE probably refers just to the last hunk, indeed. I was misled by the first two hunks, sorry for that. I currently do not have any testcase, so this is just theoretical. Could it be that code may run out of space in chunk[] around Write MNG PLTE chunk? unsigned char chunk[800]; [...] if (!need_local_plte && image->storage_class == PseudoClass && !all_images_are_gray) { unsigned long data_length; /* Write MNG PLTE chunk...
-
Thanks for both fixes (including the grammar one ;)).
-
CVE-2026-30883
-
CVE-2026-28690
-
CVE-2026-25799
-
fails with poppler 25.10
-
faill with gcc15
-
Perhaps something around https://build.opensuse.org/projects/home:pgajdos/packages/gputils/files/gputils-gcc15.patch
-
fails with gcc15
-
fails with gcc15
-
fails with gcc15
-
do not require six anymore
-
do not require six
-
Thanks Bob for the prompt reply. And I do reserve the right to ask, whether a change in behavior was intended or not to eventually adapt tests ;). Thank you!
-
montage result differ between 1.3.40 and 1.3.41
-
We could do similar check as in IW44Image.cpp (see bug #345): Index: djvulibre-3.5.28/libdjvu/IW44EncodeCodec.cpp =================================================================== --- djvulibre-3.5.28.orig/libdjvu/IW44EncodeCodec.cpp +++ djvulibre-3.5.28/libdjvu/IW44EncodeCodec.cpp @@ -1424,7 +1424,12 @@ IWBitmap::Encode::init(const GBitmap &bm int h = bm.rows(); int g = bm.get_grays()-1; signed char *buffer; - GPBuffer<signed char> gbuffer(buffer,w*h); + size_t sz = w * h; + if (sz == 0 || g <=...
-
CVE-2021-46312
-
Index: djvulibre-3.5.28/libdjvu/IW44Image.cpp =================================================================== --- djvulibre-3.5.28.orig/libdjvu/IW44Image.cpp +++ djvulibre-3.5.28/libdjvu/IW44Image.cpp @@ -676,10 +676,10 @@ IW44Image::Map::image(signed char *img8, // Allocate reconstruction buffer short *data16; size_t sz = bw * bh; + if (sz == 0) // bw or bh is zero + G_THROW("IW44Image: zero size image (corrupted file?)"); if (sz / (size_t)bw != (size_t)bh) // multiplication overflow G_THROW("IW44Image:...
-
CVE-2021-46310
-
Thanks!
-
Patch against 3.8.9.
-
Hey, could you please react, somehow ..
-
(gdb) p value $7 = 0x6020000009f0 "'" (gdb) l 1746 this. 1747 */ 1748 if ((value[0] == '\'') && (value[strlen(value)-1] == '\'')) 1749 { 1750 char nvalue[MaxTextExtent]; 1751 (void) strlcpy(nvalue,value+1,sizeof(nvalue)); 1752 nvalue[strlen(nvalue)-1]='\0'; 1753 MVGPrintf(svg_info->file,"font-family '%s'\n",nvalue); 1754 } 1755 else (gdb) strlen(nvalue) is zero
-
See for detailed analysis: https://bugzilla.suse.com/show_bug.cgi?id=1121829
-
There is #ifdef PNG_READ_EXPANDED_SUPPORTED png_free(png_ptr, png_ptr->riffled_palette); png_ptr->riffled_palette = NULL; #endif in pngwrite.c nevertheless I have two doubts: why the free is in pngwrite.c; the png_ptr->riffled_palette structure is allocated in png_do_read_transformations() from pngrtran.c and called only from pngread.c why PNG_READ_EXPANDED_SUPPORTED is used in the preprocessor condition; the structure is allocated only only if PNG_ARM_NEON_INTRINSICS_AVAILABLE is defined and this...
-
Indeed, I had not noticed there is a check against MaxColormapSize in AllocateImageColormap(). Thanks for your explanation, feel free to close.
-
Few links relating to CVE-2018-16645 http://www.cvedetails.com/cve/CVE-2018-16645/ https://github.com/ImageMagick/ImageMagick/issues/1268 https://github.com/ImageMagick/ImageMagick/commit/ecb31dbad39ccdc65868d5d2a37f0f0521250832
-
There seem to be similar issue in pict.c.
-
number_colors sanity check
-
This could be better. As it seems to be merely casting issue, I would not object against WONTFIX.
-
Ah, I see .. the patch above is obviously wrong.
-
Patch that could resolve these issue, but please review thoroughly.
-
pointer issues
-
Thank you!
-
Thanks!
-
small memory leak in rgb.c, gray.c and cmyk.c
-
ImageMagick CVE-2017-18272 applies to GraphicsMagick
1
