YYImage
YYImage copied to clipboard
Adapting to libwebp 1.3.2 will crash when calling YYCGImageCreateEncodedWebPData
libwebp has an important vulnerability called CVE-2023-4863, and it is fixed in 1.3.2 for webp. You can see more datils in WebP 堆缓冲区溢出 安全漏洞
crash stack maybe like:
Report Version: 104
crashTypeString FATAL_SIGNAL
exception EXC_CRASH (SIGABRT)
reason SIGABRT fault_address:0x00000001feadc558
fault_address: 0x00000001feadc558
Thread 96 name: xxxxxx
Thread 96: Crashed:
0 libsystem_kernel.dylib 0x00000001feadc558 ___pthread_kill (in libsystem_kernel.dylib) + 8
1 libsystem_pthread.dylib 0x000000021f75a114 _pthread_kill (in libsystem_pthread.dylib) + 264
2 libsystem_c.dylib 0x00000001c72f2174 _abort (in libsystem_c.dylib) + 176
3 libsystem_malloc.dylib 0x00000001ce2300e0 _malloc_vreport (in libsystem_malloc.dylib) + 904
4 libsystem_malloc.dylib 0x00000001ce2302c4 _malloc_report (in libsystem_malloc.dylib) + 60
5 libsystem_malloc.dylib 0x00000001ce22bb6c _find_zone_and_free (in libsystem_malloc.dylib) + 304
6 xxxxxxxxxxx 0x000000010f4997fc _YYCGImageCreateEncodedWebPData (in xxxxxxxxxxx) + 508
7 xxxxxxxxxxx 0x000000010f49f004 -[YYImageEncoder _encodeWebP] (in xxxxxxxxxxx) + 188
8 xxxxxxxxxxx 0x000000010f49f364 -[YYImageEncoder encode] (in xxxxxxxxxxx) + 152
The solution should be using WebPMemoryWriterClear(&writer);
instead of free(writer.mem);
,acording to the libwebp 's comment
// The custom writer to be used with WebPMemoryWriter as custom_ptr. Upon
// completion, writer.mem and writer.size will hold the coded data.
// writer.mem must be freed by calling WebPMemoryWriterClear.
WEBP_EXTERN int WebPMemoryWrite(const uint8_t* data, size_t data_size,
const WebPPicture* picture);
So the solution may be add libwebp.dependency 'libwebp','>= 1.3.2'
to libwebp subspec and replace YYCGImageCreateEncodedWebPData's implementation. I will make a PR later today.
webpData = CFDataCreate(CFAllocatorGetDefault(), writer.mem, writer.size);
WebPMemoryWriterClear(&writer);
WebPPictureFree(&picture);
free(buffer.data);
秀啊,我们考虑内部 fork 然后再依赖 1.3.2,目前还没发现问题