Skip to content
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

Uncaught exception: Overflow in Exiv2::DataBuf::c_data #2650

Closed
joelsgp opened this issue Jun 12, 2023 · 7 comments · Fixed by #2652
Closed

Uncaught exception: Overflow in Exiv2::DataBuf::c_data #2650

joelsgp opened this issue Jun 12, 2023 · 7 comments · Fixed by #2652
Labels

Comments

@joelsgp
Copy link

joelsgp commented Jun 12, 2023

Describe the bug

crashes when opening this particular image, dingus_nowhiskers.png

To Reproduce

Image attached:
dingus_nowhiskers
you can search dingus the cat or maxwell the cat to find it. hosted here: https://github.com/LeoDog896/maxwell/tree/main/images

Expected behavior

works as usual

Desktop (please complete the following information):

  • OS and version: arch linux
  • Exiv2 version and source: 0.28.0-1 from arch extra exiv2

Additional context

Add any other information about the problem here.

after I run mogrify -strip from imagemagick, it works like so:

File name       : bibi_nowhiskers.png
File size       : 250179 Bytes
MIME type       : image/png
Image size      : 512 x 512
bibi_nowhiskers.png: No Exif data found in the file
@joelsgp joelsgp added the bug label Jun 12, 2023
@postscript-dev
Copy link
Collaborator

@joelsgp
The exiv2 app is a simple front end to the library and is a good way to demonstrate any problems with an image. If I use the exiv2 app (exiv2-0.28.0-Linux64.tar.gz on Linux Mint 21.1) I can recreate your error.

$ exiv2 --Print xkycvt 245224405-44bb2c8a-37b1-4847-9004-b5950ef47633.png
Uncaught exception: Overflow in Exiv2::DataBuf::c_data

If I repeat the same test using exiv2-0.27.7-Linux64.tar.gz then no error is flagged although also no tags are printed.

ExifTool processes the file without warning/error but the tags displayed are PNG metadata - which Exiv2 does not currently support.

$ exiftool -g 245224405-44bb2c8a-37b1-4847-9004-b5950ef47633.png 
---- ExifTool ----
ExifTool Version Number         : 12.63
---- File ----
File Name                       : 245224405-44bb2c8a-37b1-4847-9004-b5950ef47633.png
Directory                       : .
File Size                       : 253 kB
File Modification Date/Time     : 2023:06:13 15:10:11+01:00
File Access Date/Time           : 2023:06:13 15:10:28+01:00
File Inode Change Date/Time     : 2023:06:13 15:10:28+01:00
File Permissions                : -rw-rw-r--
File Type                       : PNG
File Type Extension             : png
MIME Type                       : image/png
---- PNG ----
Image Width                     : 512
Image Height                    : 512
Bit Depth                       : 8
Color Type                      : RGB with Alpha
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Noninterlaced
Generated By                    : Generated by the Developer's Image Library (DevIL)
Author                          : 
Description                     : 
---- Composite ----
Image Size                      : 512x512
Megapixels                      : 0.262

Note: Exiv2 can read Exif metadata stored in a PNG file.

It appears that there is a new bug in Exiv2 when processing PNG files. However, I am sorry but I cannot commit more time to investigate your problem.

@kmilos
Copy link
Collaborator

kmilos commented Jun 15, 2023

The exception comes from here:

exiv2/src/pngchunk_int.cpp

Lines 113 to 114 in 5d1467b

const byte* text = data.c_data(keysize + 1);
size_t textsize = data.size() - keysize - 1;

In 0.27.x we used unsafe arithmetic on pData_ ponter directly, but that worked out ok as textsize was 0, which is still valid.

This needs to be fixed for all text chunks, i.e. tEXt, zTXt, and iTXt.

@nicolasfella
Copy link

https://bugs.kde.org/show_bug.cgi?id=470852 might be the same issue. The backtrace is

#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007ffff3cb08b3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007ffff3c5fabe in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007ffff3c4887f in __GI_abort () at abort.c:79
#4  0x00007ffff3ea4cf9 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#5  0x00007ffff3eb4f6c in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#6  0x00007ffff3eb4fd7 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
#7  0x00007ffff3eb5238 in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0x7ffff4044fe8 <typeinfo for std::out_of_range>, dest=0x7ffff3ecb720 <std::out_of_range::~out_of_range()>)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:98
#8  0x00007ffff66cc6a1 in Exiv2::DataBuf::c_data (this=0x7fffffffafd0, offset=7) at /home/nico/workspace/exiv2/src/types.cpp:180
#9  0x00007ffff65d156a in Exiv2::Internal::PngChunk::parseTXTChunk (data=..., keysize=6, type=Exiv2::Internal::PngChunk::tEXt_Chunk) at /home/nico/workspace/exiv2/src/pngchunk_int.cpp:113
#10 0x00007ffff65d0f8c in Exiv2::Internal::PngChunk::decodeTXTChunk (pImage=0xdb15a0, data=..., type=Exiv2::Internal::PngChunk::tEXt_Chunk) at /home/nico/workspace/exiv2/src/pngchunk_int.cpp:54
#11 0x00007ffff6700d30 in Exiv2::PngImage::readMetadata (this=0xdb15a0) at /home/nico/workspace/exiv2/src/pngimage.cpp:435
#12 0x00007ffff7d0146e in Gwenview::Exiv2ImageLoader::load (this=0x7fffffffb2b8, filePath=...) at /home/nico/kde/src/gwenview/lib/exiv2imageloader.cpp:88
#13 0x00007ffff7d5728d in Gwenview::TimeUtils::CacheItem::updateFromExif (this=0x14ac728, url=...) at /home/nico/kde/src/gwenview/lib/timeutils.cpp:87
#14 0x00007ffff7d57120 in Gwenview::TimeUtils::CacheItem::update (this=0x14ac728, fileItem=...) at /home/nico/kde/src/gwenview/lib/timeutils.cpp:74
#15 0x00007ffff7d57024 in Gwenview::TimeUtils::dateTimeForFileItem (fileItem=..., cachePolicy=Gwenview::TimeUtils::UseCache) at /home/nico/kde/src/gwenview/lib/timeutils.cpp:139

@debianmain1
Copy link

debianmain1 commented Jun 17, 2023

After updating from 0.27.6-2 to 0.28.0-1 exiv2 & 0.14.0.-3 to 0.14.1-1 libgexiv2 ( Arch via EndeavourOS ), I am running into the same issue. Information here: https://forum.endeavouros.com/t/interesting-shotwell-problem-segfault-from-exiv2-solved/41795 Downgrading returned normal function to Shotwell. I currently have those updates blocked.

@eworm-de
Copy link

The fix has been cherry-picked in Arch Linux package exiv2 0.28.0-2.

@joelsgp
Copy link
Author

joelsgp commented Jun 21, 2023

image

confirmed working fine now, thanks

@debianmain1
Copy link

Also confirmed here as working...Thank You!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants