-
Notifications
You must be signed in to change notification settings - Fork 609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SEGV in function png_free_data #238
Comments
Concretely speaking, the recommended error handling for if (setjmp(png_jmpbuf(png_ptr)))
{
png_destroy_read_struct(&png_ptr, &info_ptr, NULL);
fclose(fp);
return (ERROR);
} results in a SEGV during The error occurs in You can test it with simple (non-incremental) reads via @fouzhe's fuzzy-file here. |
@fouzhe can you try if you can reproduce that issue also with
libpng error: Read Error
PNG2PNM
Error: unsuccessful conversion of PNG-image
================================================================= Direct leak of 160 byte(s) in 1 object(s) allocated from: Indirect leak of 2400 byte(s) in 1 object(s) allocated from: SUMMARY: AddressSanitizer: 2560 byte(s) leaked in 2 allocation(s). |
Yeah,I will try it! |
yes, via: here is my diff to get it compiled with clang-6.0: export CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" CC=clang-6.0
./autogen.sh
./configure
cd contrib/pngminus/
make -f makefile.std
./png2pnm crash_SEGV_readfromfile crash.pnm diff --git a/contrib/pngminus/makefile.std b/contrib/pngminus/makefile.std
index 14e25cd64..553bbe354 100644
--- a/contrib/pngminus/makefile.std
+++ b/contrib/pngminus/makefile.std
@@ -2,7 +2,7 @@
# Linux / Unix
#CC=cc
-CC=gcc
+CC=clang-6.0
LD=$(CC)
RM=rm -f
@@ -13,18 +13,19 @@ RM=rm -f
#PNGLIBS = $(PNGPATH)/lib/libpng16.a
PNGINC = -I../..
PNGLIB = -L../.. -lpng
-PNGLIBS = ../../libpng.a
+PNGLIBS = ../../.libs/libpng16.a
-#ZPATH = /usr/local
-#ZINC = -I$(ZPATH)/include
-#ZLIB = -L$(ZPATH)/lib -lz
+ZPATH = /usr/local
+ZINC = -I$(ZPATH)/include
+ZLIB = -L$(ZPATH)/lib -lz
#ZLIBS = $(ZPATH)/lib/libz.a
-ZINC = -I../../../zlib
-ZLIB = -L../../../zlib -lz
:...skipping...
diff --git a/contrib/pngminus/makefile.std b/contrib/pngminus/makefile.std
index 14e25cd64..553bbe354 100644
--- a/contrib/pngminus/makefile.std
+++ b/contrib/pngminus/makefile.std
@@ -2,7 +2,7 @@
# Linux / Unix
#CC=cc
-CC=gcc
+CC=clang-6.0
LD=$(CC)
RM=rm -f
@@ -13,18 +13,19 @@ RM=rm -f
#PNGLIBS = $(PNGPATH)/lib/libpng16.a
PNGINC = -I../..
PNGLIB = -L../.. -lpng
-PNGLIBS = ../../libpng.a
+PNGLIBS = ../../.libs/libpng16.a
-#ZPATH = /usr/local
-#ZINC = -I$(ZPATH)/include
-#ZLIB = -L$(ZPATH)/lib -lz
+ZPATH = /usr/local
+ZINC = -I$(ZPATH)/include
+ZLIB = -L$(ZPATH)/lib -lz
#ZLIBS = $(ZPATH)/lib/libz.a
-ZINC = -I../../../zlib
-ZLIB = -L../../../zlib -lz
-ZLIBS = ../../../zlib/libz.a
+#ZINC = -I../../../zlib
+#ZLIB = -L../../../zlib -lz
+#ZLIBS = ../../../zlib/libz.a
CPPFLAGS=$(PNGINC) $(ZINC)
-CFLAGS=
+CFLAGS=-g -fsanitize=address
+LDFLAGS=-fsanitize=address
LDLIBS=$(PNGLIB) $(ZLIB)
LDLIBSS=$(PNGLIBS) $(ZLIBS)
C=.c
@@ -41,19 +42,19 @@ png2pnm$(O): png2pnm$(C)
$(CC) -c $(CPPFLAGS) $(CFLAGS) png2pnm$(C)
png2pnm$(E): png2pnm$(O)
- $(LD) $(LDFLAGS) -o png2pnm$(E) png2pnm$(O) $(LDLIBS) -lm
+ $(LD) $(LDFLAGS) -o png2pnm$(E) png2pnm$(O) $(LDLIBS) -lm -lz
png2pnm-static$(E): png2pnm$(O)
- $(LD) $(LDFLAGS) -o png2pnm-static$(E) png2pnm$(O) $(LDLIBSS) -lm
+ $(LD) $(LDFLAGS) -o png2pnm-static$(E) png2pnm$(O) $(LDLIBSS) -lm -lz
pnm2png$(O): pnm2png$(C)
$(CC) -c $(CPPFLAGS) $(CFLAGS) pnm2png$(C)
pnm2png$(E): pnm2png$(O)
- $(LD) $(LDFLAGS) -o pnm2png$(E) pnm2png$(O) $(LDLIBS) -lm
+ $(LD) $(LDFLAGS) -o pnm2png$(E) pnm2png$(O) $(LDLIBS) -lm -lz
pnm2png-static$(E): pnm2png$(O)
- $(LD) $(LDFLAGS) -o pnm2png-static$(E) pnm2png$(O) $(LDLIBSS) -lm
+ $(LD) $(LDFLAGS) -o pnm2png-static$(E) pnm2png$(O) $(LDLIBSS) -lm -lz
clean:
$(RM) png2pnm$(O) |
@ax3l Thank you very much for the information provided! export CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" CC=clang-6.0
./autogen.sh
./configure
make
cd contrib/pngminus/
make -f makefile.std
|
I think another issue can be opened to report this issue! |
this issue was assigned as this CVE number : |
Ok, but admittedly we still try to reproduce the downstream issue herein. @fouzhe could you reproduce the SEGV with a reduced, pure libpng example? I have a hard time proving anything else but the mem leak in #239 right now. |
Hi. I'm following up your conversation. Just to confirm: I'm using I tried png2pnm with ASAN from clang-6.0, and Valgrind on top of that. Other than the memory leak from #239 (which I confirm), everything is running fine. Are you sure it's a bug in libpng, and not in pngwriter? |
I took a closer look at the test case. Looks like IDAT is abnormally large, as well as unfinished. There's nothing else special about that, as far as I can see. Libpng should be able to handle that case, correctly. Here's an idea: try recompiling pngwriter with either a new clang or a new gcc, but with Alternatively, re-engineer pngwriter using C++ exception handling, if you're willing to take that path. |
Thanks for taking a closer look! I suspect the same since I have a hard time reproducing it in the minimal It seems somehow that during |
@ax3l I'm now reproducing the SEGV in png2pnm using gdb! |
@ctruta We used pure png2pnm in libpng and got memory leak using attached file! |
I just renamed that issue, for correctness. The crash is in the 3rd-party pnm2png (importantly not in png2pnm), so it's not about a specially-crafted input that can crash libpng. It's rather about crashing a sample program in a place that's outside of the scope of libpng. |
The fix is in the master branch and in the public release libpng-1.6.37. |
I'm a bit confused what exactly the fix for this issue was. |
@ctruta, what was the commit?
|
The commit 1f0221f does indeed fix the SEGV (i.e. this issue). The memory leak is an unrelated issue. |
... I see: SEGV is not a crash produced by libpng, or by pngminus. It's a result of ASAN. |
maybe, If I do not ship the binary of pnm2png,i will not affected by CVE-2018-14048 ? |
Is CVE-2018-14048 and CVE-2018-14047 the same problem solved? |
Is CVE-2018-14048 fixed? |
Hi,has the vulnerability CVE-2018-14048 been fixed? |
asking the same as above? Has CVE-2018-14048 been fixed? |
Yes, the SEGV issue that remains here is not a problem within libpng. The problem is that pngwriter has some undefined behavior that confuses ASAN, and this can be fixed by adding an error handler at the right place in pngwriter, see full details. There are also reports of a memory leak within |
Hi,all!
We find a bug in libpng 1.6.34 when using pngwriter,which take libpng as dependence.
You can get more information by inferring this!
The text was updated successfully, but these errors were encountered: