Activity for Sebastian Pipping
-
Sebastian Pipping created ticket #135
[1.6.1] Five tests are failing with libxml2 >=2.13.5
-
PS: For anyone who likes to play with the issue in isolation, a minimal reproducer is this: # LANG='invalid value' python3 -c 'import locale; locale.setlocale(locale.LC_ALL, "")' Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3.11/locale.py", line 627, in setlocale return _setlocale(category, locale) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ locale.Error: unsupported locale setting
-
While this seems fixed in Git, I have hit this issue with the latest release 0.21.2. Please consider cutting a new release with the fix. Thank you!
-
[7.9.1] CMake build system installs optipng binary without executable permissions
-
@thecybersandeep greetings, any updates on the topics of CVE number and/or availability of a patch? Thanks!
-
@bcodres thanks! At https://nvd.nist.gov/vuln/detail/CVE-2022-28506 I found… giflib_poc asan_report_giflib.png …now and I confirm your results. I think that means that we have four CVEs all being about the same thing… CVE-2022-28506 CVE-2023-48161 CVE-2024-45993 CVE-2025-31344 …, that the previous fix was incomplete, and that giflib-5.2.2-cve-2025-31344.patch completes it. Thanks for your help! Best, Sebastian
-
I checked Git masteragainst the two cases just now. The first case — command ./gif2rgb -s — I confirm as fixed (by commit 38e39296dea689c0ca972f6abb2e6cc180dfbd8f that is attributed to issue 153). The second case — command yes '' | ./gif2rgb -s 1 2 — fails with the exact same LeakSanitizer output on master of today (at 8bed392c280ad2c237e8bf1beca6f8f68f893e87).
-
@bcodres @mmuzila since related commit 368f28c0034ecfb6dd4b3412af4cc589a56e0611 says CVE-2022-28506 rather than CVE-2024-45993 I assume that CVE-2022-28506 is the same also?
-
@bcodres I agree — CVE-2024-45993 is the same! I just confirmed with a debugger that @mmuzila's file crashes/sample hits the same code path. What only now I realize is that the issue (likely) appeared fixed to some (or some of the time), because whether the user passes argument -1 or not — for single-file mode, in contrast to three-file mode — decides whether they run vulnerable code or not: they either run (a) the code with the fix from 368f28c0034ecfb6dd4b3412af4cc589a56e0611 for single-file mode...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
The attached out-of-memory-expection-or-memory-leak.gif is 32 bytes in size and has a screen size of 65503x65503 in its header. While processing that file, gif2rgb allocates 65503x65503 (circa 4 GiB) rather early (in a nested loop) and then runs into error handling code due to the file's use of an invalid extension. Allocating later — delaying the allocation — may help this very case but it would not fix the core issue. If I am not mistaken GIF (https://www.w3.org/Graphics/GIF/spec-gif89a.txt) allows...
-
@thecybersandeep maybe I overlooked something — did you create a patch? Are you aware of a patch for this by anyone else?
-
@bcodres I confirm that the patch fixes the crash for the attached POC_crash file. As a consequence, this seems to mean that CVE-2023-48161 and CVE-2025-31344 are the very same thing, see https://github.com/OpenMandrivaAssociation/giflib/blob/master/giflib-5.2.2-cve-2025-31344.patch and https://seclists.org/oss-sec/2025/q2/25 . Can you confirm? CC @ctulhu
-
@esr I just tried with vanilla giflib 5.2.2 (plus ASan plus UBSan a la make {O,LD}FLAGS='-fsanitize=address,undefined' CC=clang) and the POC_crash file attached by @tihanyin makes command ./gif2rgb -o out POC_crash crash with the same output as reported. This is not fixed, please fix. Thank you! CC @ctulhu
-
Hello @bale, FYI if I am not mistaken then this is the same thing that is being discussed as CVE-2025-31344 on https://seclists.org/oss-sec/2025/q2/21 at this very moment.
-
-Wformat-truncation likely pointing out an actual bug
-
@thecybersandeep perfect, thank you!
-
I used git bisect now and found that releases <5.1.5 are affected. Commit https://sourceforge.net/p/giflib/code/ci/ea8dbc5786862a3e16a5acfa3d24e2c2f608cd88/ has an apparent fix, issue #87 is related. CC @ctulhu
-
@thecybersandeep are you aware of any CVE assigned to or requested for this?
-
Even with patch https://sourceforge.net/p/giflib/code/ci/ccbc956432650734c91acb3fc88837f7b81267ff/ applied, master seems to still use 5 GB of RAM/RSS to process that 32 bytes file before aborting with error GIF-LIB error: Wrong record type detected. So the issue seems unfixed to me. CC @ctulhu
-
@esr I just tried with vanilla giflib 5.2.2 (plus ASan plus UBSan a la make {O,LD}FLAGS='-fsanitize=address,undefined' CC=clang) and the POC_crash file attached by @tihanyin makes command gif2rgb -o out POC_crash crash with the same output as reported. This is not fixed, please fix. Thank you! CC @ctulhu
-
@bcodres the patched you attached — both the initial and the rebased one — only add three calls to free which I would expect to be able to fix a memory leak but not a buffer overflow. Am I missing something? Could you verify the patch files contains what you intended to share for a fix? Thank you! CC @ctulhu
-
@esr I just tried with vanilla giflib 5.2.2 (plus ASan plus UBSan a la make {O,LD}FLAGS='-fsanitize=address,undefined' CC=clang) and the POC_crash file attached by @bcodres makes command gif2rgb -o out POC_crash crash with the same output as reported. This is not fixed, please fix. Thank you! CC @ctulhu
-
PS: Here's a version of the patch with the file path adjusted to fit GNU/Linux distros out of the box. Gentoo now has that patch applied to its package app-text/docbook2X.
-
[0.8.8] File l10n-set.xml
-
I read how pycxx is packaged for fedora and its using setup.py - but distutils can be imported. I'm not sure why that is working like that. Why is distutil available on Fedora? distutils may be importable with 3.12 in some places but upstream https://docs.python.org/3.11/library/distutils.html are clear in "deprecated with removal planned for Python 3.12" and the official docs no longer contain a page for that package for 3.12; it's officially removed with regard to CPython upstream. I will investigate...
-
Hi Barry, I believe the Gentoo package dev-python/pycxx that brought me here uses setup.py and not setup_makefile.py. After a quick look at the Makefile that command python3 setup_makefile.py linux Makefile produced, my impression is: - that it does not have an install target - that the produced files obj/simple.so obj/example.so obj/pycxx_iter.so are not essential (but you tell me) - that g++ would need to be a variable, e.g. $(CXX) - that -g should come from $(CFLAGS) and $(LDFLAGS) to respect...
-
distutils not removed from setup.py?
-
Thanks, Cosmin! OptiPNG is at 0.7.8 in Gentoo now.
-
Hi Cosmin, would you recommend Thomas' patch for application as-is in Linux distros before the is a release 0.7.8? I think distros would want to patch before 0.7.8 unless it's only a few days away. Is there anything making sure that "curbit + code_size" cannot overflow btw? Best!
-
@zengyx is there a patch for this?
-
Thanks for this fix, I have applied it now in Gentoo Linux https://github.com/gentoo/gentoo/commit/0f0ba1c7b1f617b17eb0b946a5f63e92b3320a01
-
lv_color.c:263: possible bad shift ?
-
Closing as fixed in 0.4.1…
-
Related: https://github.com/Libvisual/libvisual/pull/142
-
XML_ERROR_INVALID_TOKEN on a legal xml character
-
Closing as a duplicate of https://sourceforge.net/p/expat/bugs/292/ .
-
Support for XML 1.1 (and XML 1.0r5)
-
Closing as a duplicate of https://sourceforge.net/p/expat/bugs/292/ .
-
XMLWF rejects XML file
-
Project moved to GitHub
-
Thanks, I have updated Gentoo to 1.9.15 just now.
-
Okay great, thanks for sharing your time constraints. See you.
-
Hi Barry, The -g is controlled by the --enable-debug option. SInce you do not use that option I'm not sure what the problem could be? There are more places in there that add -g — that made me bring it up. It seems like none of these cases affect Linux though, not even the one in UnixCompilerGCC.setupUtilities while expected. So the fix probably already works for Linux (but not for macOS if that matters). I did leave -g on the generate_svn_error_codes build tool, but you do not install that so I'm...
-
Hi Barry, thanks for your work in this direction. To respect the rules of packaging for Gentoo myself, I would still need to patch the nine or so places with -g away because the end user (where the compiling happens) is expected full control. (For a workaround in packaging, I'm unsure if present -g can be fully negated by appending, but it doesn't seem very robust). Would you be up for making addition of -g suppressible some way? PS: What are your thoughts on the part for Patches/test_proplist.mak...
-
Hi Barry, thanks for your work in this direction. To respect the rules of packaging for Gentoo myself, I would still need to patch the nine or so places with -g away because the end user (where the compiling happens) is expected full control. (For a workaround in packaging, I'm unsure if present -g can be fully negated by appending, but it doesn't seem very robust). Would you be up for making addition of -g suppressable some way? PS: What are your thoughts on the part for Patches/test_proplist.mak...
-
Cool! This is what comes to mind with regard to "only if defined": Python: os.environ.setdefault('CC', 'gcc') Makefile a: CC ?= gcc (shy) Makefile b: CC = gcc with make CC=[..] (rather than CC=[..] make, order matters)
-
[PATCH] Please make the build system respect variables CC, CXX, LDFLAGS
-
Barry, I tried to upgrade packaging of pysvn to 1.9.13 for Gentoo and then ran into this issue here. I found a workaround (https://github.com/gentoo/gentoo/blob/50cd663733598e3c53c2918ed4f4690740d65b60/dev-python/pysvn/pysvn-1.9.13.ebuild#L39-L44) but it would be nice if the release of 1.9.14 could be finished so that I can clean up those workarounds. Thank you!
-
Parser will not identify absolute URLs correctly
-
Bug moved to GitHub: https://github.com/uriparser/uriparser/issues/2 Closing.
-
Query String Parser return wrong value
-
Hi! I found this bug to be a duplicate of bug 12 (ex 3590761) now and to be fixed since uriparser 0.7.8 by commit abb4153da87117c3c14f3fd5fb5f7df148232b2e. This is what I did on the shell to find it: # git diff uriparser-0.7.5 master -- {lib,src}/UriQuery.c [..] # git blame -- src/UriQuery.c | fgrep 'if (walk + 1 <= afterLast) {' abb4153d src/UriQuery.c (Sebastian Pipping 2012-12-10 00:38:23 +0100 426) if (walk + 1 <= afterLast) { # git show abb4153d [..] # git tag --contains abb4153d | head -n 1...
-
Query String Parser return wrong value
-
Parsing fails when URL ends with empty query parameter value
-
Hello Stefan, I recall that absolutePath only is set for URLs without a host present. So if it is a bug, you could check for presence of a host first, for a workaround. Best, Sebastian
-
Hello Stefan, I recall that absolutePath only is set for URLs with a host present. So if it is a bug, you could check for presence of a host first, for a workaround. Best, Sebastian
-
Hi Parteek, I cannot confirm that behavior with Git master. Please check this new test case and report back: https://sourceforge.net/p/uriparser/git/ci/4e87336dfb675fadd30c65cfc3a64d62c34c05d6/
-
This issue got assigned CVE number CVE-2017-16938 in the meantime, so for reference: https://nvd.nist.gov/vuln/detail/CVE-2017-16938
-
Adding CVE link https://nvd.nist.gov/vuln/detail/CVE-2017-1000229 for completeness.
-
Here's my take on a portable patch.
-
Here's a patch candidate for review. Output with the patch applied from a Debian sid i386 chroot: $ ./src/optipng/optipng poc.tiff ** Processing: poc.tiff Error: Out of memory ** Status report 1 file(s) have been processed. 1 error(s) have been encountered.
-
Here's a patch candidate for review. Output with the patch applied form a Debian sid i386 chroot: $ ./src/optipng/optipng poc.tiff ** Processing: poc.tiff Error: Out of memory ** Status report 1 file(s) have been processed. 1 error(s) have been encountered.
-
pngxmem.c:37:32: warning: comparison is always false due to limited range of data type [-Wtype-limits]
-
Home
-
Hi Mrinal, you seem to be looking for XInclude (https://en.wikipedia.org/wiki/XInclude). Please note that Expat moved to GitHub. Fox XInclude, there is this ticket: https://github.com/libexpat/libexpat.github.io/issues/10
-
Hi Nick, thanks for the report! Should be fixed by https://sourceforge.net/p/uriparser/git/ci/048fc15e1667b8d34fad5211f97e19d375b91fc0/ on Git master now. I'm happy to use your full realname in the change log for credit instead if you share it with me trough some channel. Best, Sebastian
-
Max size of destination buffer in UriStringToWindowsFilename
-
I had a closer look now and consider the cause outside of Expat, see https://github.com/libexpat/libexpat/issues/143#issuecomment-328603563 . Please re-open the ticket on GitHub with further details if my analysis seemed anything. Thanks!
-
XML_ERROR_UNCLOSED_TOKEN when parse some Chinese characters
-
A quick update: I searched and found MSDN documention on calling conventions now [1], found how to integrate an stdcall switch to CMake build systems for debugging [2], was then able to reproduce the problem on AppVeyor [3], tried that wrapper idea mentioned above (patch attached) and ran into more errors related to stdcall then [4]. So my impression is that cdecl is the only supported default calling convention at the moment and to support stdcall would need a bit more. Is that something you would...
-
Thanks, Marc!
-
XMLWF rejects XML file
-
A quick update: I search and found MSDN documention on calling conventions now [1], found how to integrate an stdcall switch to CMake build systems for debugging [2], was then able to reproduce the problem on AppVeyor [3], tried that wrapper idea mentioned above (patch attached) and ran into more errors related to stdcall then [4]. So my impression is that cdecl is the only supported default calling convention at the moment and to support stdcall would need a bit more. Is that something you would...
-
Hi Arno, but expat should at least compile with the stdcall switch With that said, I'm starting to understand now that we have these lines in Expat and they are the trouble ones: mtemp->malloc_fcn = malloc; mtemp->realloc_fcn = realloc; mtemp->free_fcn = free; I guess if we did a trick like #if defined(_MSC_VER) static void * _EXPAT_malloc(size_t size) { return malloc(size); } #else # define _EXPAT_malloc malloc #endif [..] mtemp->malloc_fcn = _EXPAT_malloc; it would work with either calling convention...
-
Hi Arno, but expat should at least compile with the stdcall switch With that said, I'm starting to understand now that we have these lines in Expat and they are the trouble ones: mtemp->malloc_fcn = malloc; mtemp->realloc_fcn = realloc; mtemp->free_fcn = free; I guess if we did a trick like #if defined(_MSC_VER) static void _EXPAT_malloc(size_t size) { malloc(size); } #else # define _EXPAT_malloc malloc #endif [..] mtemp->malloc_fcn = _EXPAT_malloc; it would work with either calling convention at...
-
Hi Arno, but expat should at least compile with the stdcall switch With that said, I'm starting to understand now that we have these lines in Expat and they are the trouble ones: mtemp->malloc_fcn = malloc; mtemp->realloc_fcn = realloc; mtemp->free_fcn = free; I guess if we did a trick like #if defined(_MSC_VER) static void _EXPAT_malloc(size_t size) { malloc(size); } #else # define _EXPAT_malloc malloc #endif [..] mtemp->malloc_fcn = _EXPAT_malloc; it would work with either calling convention at...
-
Seems obsolete, closing.
-
predefined entities...
-
Seems obsolete. If not, please provide a pull request at https://github.com/libexpat/libexpat , Closing.
-
Build issues on Symbian and BREW
-
Fix cmake file to install libs in the right path on 64 bit systems
-
No reply for a year, closing as obsolete.
-
Hi! There seem to be two main aspects here: Migration to GNU Automake and supporting Windows CE. For Automake, we use that on Git master by now. For Windows CE, if it still matters, please make a pull request against latest master on GitHub: https://github.com/libexpat/libexpat Thanks!
-
New libtool, use automake, port to windows ce
-
No reply for more than a year, closing as obsolete.
-
Export a CMake Config file
-
We have this code in by now: return (XML_Index)(parseEndByteIndex - (parseEndPtr - eventPtr)); If you still get warnings, please open a new ticket or pull request at GitHub: https://github.com/libexpat/libexpat/issues/
-
Patch to prevent compiler warning when building for 64-bit
-
I suppose this ticket is obsolete. If it's not, regarding the packaging team has request an email from the vendor stating that they will support the application if it has been packaged with App V no we don't, sorry; closing.
-
XML Parser packaged with APP V
-
Files needed to build expat using VS2005
1 >
