3267 words
16 minutes
Fuzz two legacy CVEs in libexif
2026-02-24
2026-03-01

Target CVEs#

Description#

Compile#

Download#

Terminal window
git clone https://github.com/libexif/libexif.git
cd libexif && git checkout libexif-0_6_14-release

Build#

这里由于我在 make 的时候有关生成文档的地方报错了,所以我手动将文档部分 patch 掉:

Makefile.am
SUBDIRS = m4m po libexif test doc binary
SUBDIRS = m4m po libexif test binary
Terminal window
autoreconf -fvi
CC=clang CXX=clang++ CFLAGS="-O0 -g -fno-inline -fno-builtin -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" ./configure --enable-shared=no --prefix="$PWD/../workshop/lib-debug/"
make -j`nproc` && make install
make clean
CC=afl-clang-lto CXX=afl-clang-lto++ ./configure --enable-shared=no --prefix="$PWD/../workshop/lib-fuzz/"
make -j`nproc` && make install

由于 libexif 只是一个库,所以我们要 fuzz 它需要自己找个前端,或者手写 harness 。方便起见,我直接使用 exif 作为前端。

Terminal window
git clone https://github.com/libexif/exif.git
cd exif && git checkout exif-0_6_15-release
autoreconf -fvi
CC=clang CXX=clang++ CFLAGS="-O0 -g -fno-inline -fno-builtin -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" PKG_CONFIG_PATH="$PWD/../workshop/lib-debug/lib/pkgconfig/" ./configure --enable-shared=no --prefix="$PWD/../workshop/exif-debug"
make -j`nproc` && make install
make clean
CC=afl-clang-lto CXX=afl-clang-lto++ PKG_CONFIG_PATH="$PWD/../workshop/lib-fuzz/lib/pkgconfig/" ./configure --enable-shared=no --prefix="$PWD/../workshop/exif-fuzz"
make -j`nproc` && make install

Samples#

gen_corpus.py
#!/usr/bin/env python3
import struct
import os
def pack_data(fmt, endian, *args):
return struct.pack(('<' if endian == 'LE' else '>') + fmt, *args)
class ExifGenerator:
def __init__(self, endian='LE'):
self.endian = endian
self.entries = []
self.data_blobs = b''
def add_entry(self, tag, data_type, count, value):
self.entries.append({'tag': tag, 'type': data_type, 'count': count, 'value': value})
def build_ifd(self, start_offset, next_ifd_offset=0):
ifd_data = pack_data('H', self.endian, len(self.entries))
data_offset = start_offset + 2 + (len(self.entries) * 12) + 4
entry_bytes = b''
blob_bytes = b''
for e in self.entries:
val_bytes = b''
raw_blob = None
if e['type'] == 1: # BYTE
if isinstance(e['value'], int): raw_blob = pack_data('B', self.endian, e['value'])
else: raw_blob = e['value']
elif e['type'] == 2: # ASCII
raw_blob = e['value'].encode('ascii') + b'\x00'
elif e['type'] == 3: # SHORT
if e['count'] == 1: raw_blob = pack_data('H', self.endian, e['value'])
else: raw_blob = pack_data('H'*e['count'], self.endian, *e['value'])
elif e['type'] == 4: # LONG
if e['count'] == 1: raw_blob = pack_data('I', self.endian, e['value'])
else: raw_blob = pack_data('I'*e['count'], self.endian, *e['value'])
elif e['type'] == 5: # RATIONAL
raw_blob = pack_data('II', self.endian, e['value'][0], e['value'][1])
elif e['type'] == 7: # UNDEFINED
raw_blob = e['value']
elif e['type'] == 10: # SRATIONAL
raw_blob = pack_data('ii', self.endian, e['value'][0], e['value'][1])
if len(raw_blob) <= 4:
val_bytes = raw_blob.ljust(4, b'\x00')
else:
off = data_offset + len(blob_bytes)
val_bytes = pack_data('I', self.endian, off)
blob_bytes += raw_blob
entry_bytes += pack_data('HHII', self.endian, e['tag'], e['type'], e['count'], struct.unpack('<I' if self.endian == 'LE' else '>I', val_bytes)[0])
return ifd_data + entry_bytes + pack_data('I', self.endian, next_ifd_offset) + blob_bytes
def create_complex_exif(endian='LE'):
# 1. Build Exif SubIFD
exif = ExifGenerator(endian)
exif.add_entry(0x9003, 2, 20, "2026:02:24 14:00:00")
exif.add_entry(0x829a, 5, 1, (1, 100))
exif.add_entry(0x829d, 5, 1, (28, 10))
exif.add_entry(0x9204, 10, 1, (-1, 3))
exif.add_entry(0x9286, 7, 8, b"USERCOM\x00")
exif_sub_data = exif.build_ifd(0) # Length check only first
# 2. Build GPS IFD
gps = ExifGenerator(endian)
gps.add_entry(0x0000, 1, 4, b'\x02\x02\x00\x00')
gps.add_entry(0x0002, 5, 3, (1, 1)) # This will actually need 3 rationals, but let's keep it simple
# Fix: GPS Latitude is 3 rationals
gps.entries[-1] = {'tag': 0x0002, 'type': 5, 'count': 3, 'value': (40, 1, 30, 1, 15, 1)}
gps_data = gps.build_ifd(0)
# 3. Build IFD0
ifd0 = ExifGenerator(endian)
ifd0.add_entry(0x010e, 2, 11, "Fuzz Test")
ifd0.add_entry(0x0110, 2, 11, "Gemini Cam")
ifd0.add_entry(0x8769, 4, 1, 0) # ExifOffset
ifd0.add_entry(0x8825, 4, 1, 0) # GPSInfo
# IFD0 fixed size: 2 + 4*12 + 4 = 54. Blobs: 11 + 11 = 22. Total = 76.
ifd0_total_len = 76
exif_offset = 8 + ifd0_total_len
gps_offset = exif_offset + len(exif_sub_data)
for e in ifd0.entries:
if e['tag'] == 0x8769: e['value'] = exif_offset
if e['tag'] == 0x8825: e['value'] = gps_offset
final_ifd0 = ifd0.build_ifd(8)
final_exif = exif.build_ifd(exif_offset)
final_gps = gps.build_ifd(gps_offset)
header = b'II\x2a\x00\x08\x00\x00\x00' if endian == 'LE' else b'MM\x00\x2a\x00\x00\x00\x08'
return header + final_ifd0 + final_exif + final_gps
def save_corpus(name, data, add_exif_header=False):
os.makedirs('corpus/exif', exist_ok=True)
with open(os.path.join('corpus/exif', name), 'wb') as f:
if add_exif_header: f.write(b'Exif\x00\x00')
f.write(data)
print(f"Created {name}")
if __name__ == "__main__":
save_corpus('rich_le.exif', create_complex_exif('LE'), True)
save_corpus('rich_be.exif', create_complex_exif('BE'), True)
SOI, APP1 = b'\xff\xd8', b'\xff\xe1'
exif_payload = b'Exif\x00\x00' + create_complex_exif('LE')
app1_data = APP1 + struct.pack('>H', len(exif_payload) + 2) + exif_payload
save_corpus('rich_jpeg.jpg', SOI + app1_data + b'\xff\xd9')
save_corpus('raw_tiff.exif', create_complex_exif('LE'), False)

Fuzzing#

AFLplusplus go work: afl-fuzz -i - -o out/ -s 1337 -- ./exif-fuzz/bin/exif @@.

这个 Gemini Cam 还挺滑稽的哈哈哈:

13 个 crashes,4 个 hangs,其中有这几种独立的 crash 情况:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e595c1 in memcpy () from /usr/lib64/libc.so.6
#0 0x00007ffff7e595c1 in memcpy () from /usr/lib64/libc.so.6
#1 0x0000555555565553 in exif_data_load_data_thumbnail (data=0x5555555931e0, d=0x555555595986 "II*", ds=256, offset=4294967168, size=232) at exif-data.c:292
#2 0x0000555555563d05 in exif_data_load_data_content (data=0x5555555931e0, ifd=EXIF_IFD_EXIF, d=0x555555595986 "II*", ds=256, offset=86, recursion_depth=1) at exif-data.c:381
#3 0x0000555555563b36 in exif_data_load_data_content (data=0x5555555931e0, ifd=EXIF_IFD_0, d=0x555555595986 "II*", ds=256, offset=10, recursion_depth=0) at exif-data.c:361
#4 0x0000555555563621 in exif_data_load_data (data=0x5555555931e0, d_orig=0x555555595980 "Exif", ds_orig=262) at exif-data.c:813
#5 0x000055555556cb9b in exif_loader_get_data (loader=0x555555593190) at exif-loader.c:387
#6 0x000055555555f73e in main (argc=2, argv=0x7fffffffdca8) at main.c:438
Program received signal SIGSEGV, Segmentation fault.
0x000055555556e60f in exif_get_slong (b=0x5555555b2000 <error: Cannot access memory at address 0x5555555b2000>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:129
129 return ((b[3] << 24) | (b[2] << 16) | (b[1] << 8) | b[0]);
#0 0x000055555556e60f in exif_get_slong (b=0x5555555b2000 <error: Cannot access memory at address 0x5555555b2000>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:129
#1 0x000055555556e49f in exif_get_long (buf=0x5555555b2000 <error: Cannot access memory at address 0x5555555b2000>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:156
#2 0x0000555555566026 in exif_entry_fix (e=0x555555593460) at exif-entry.c:189
#3 0x0000555555562d6d in fix_func (e=0x555555593460, data=0x0) at exif-content.c:211
#4 0x0000555555562a13 in exif_content_foreach_entry (content=0x555555593270, func=0x555555562d50 <fix_func>, data=0x0) at exif-content.c:185
#5 0x0000555555562bdc in exif_content_fix (c=0x555555593270) at exif-content.c:225
#6 0x0000555555565481 in fix_func (c=0x555555593270, data=0x0) at exif-data.c:1082
#7 0x00005555555650ca in exif_data_foreach_content (data=0x5555555931e0, func=0x5555555653e0 <fix_func>, user_data=0x0) at exif-data.c:965
#8 0x00005555555643d4 in exif_data_fix (d=0x5555555931e0) at exif-data.c:1087
#9 0x0000555555563886 in exif_data_load_data (data=0x5555555931e0, d_orig=0x555555595980 "", ds_orig=82) at exif-data.c:826
#10 0x000055555556cbeb in exif_loader_get_data (loader=0x555555593190) at exif-loader.c:368
#11 0x000055555555f75e in main (argc=2, argv=0x7fffffffdbe8) at main.c:438
Program received signal SIGSEGV, Segmentation fault.
0x000055555556e3d2 in exif_get_sshort (buf=0x555655595985 <error: Cannot access memory at address 0x555655595985>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:92
92 return ((buf[1] << 8) | buf[0]);
#0 0x000055555556e3d2 in exif_get_sshort (buf=0x555655595985 <error: Cannot access memory at address 0x555655595985>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:92
#1 0x000055555556e33f in exif_get_short (buf=0x555655595985 <error: Cannot access memory at address 0x555655595985>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:100
#2 0x0000555555563671 in exif_data_load_data (data=0x5555555931e0, d_orig=0x555555595980 "Exif", ds_orig=61) at exif-data.c:775
#3 0x000055555556cbeb in exif_loader_get_data (loader=0x555555593190) at exif-loader.c:368
#4 0x000055555555f75e in main (argc=2, argv=0x7fffffffdbe8) at main.c:438

hang 的情况比较唯一,全是卡在 exif_loader_write 这里:

这里附赠一个我看各个崩溃回溯的脚本:

#!/usr/bin/env bash
TARGET="./exif-debug/bin/exif"
CRASH_DIR="./out/default/crashes"
OUTPUT_LOG="crash_reports.txt"
>"$OUTPUT_LOG"
echo "[+] Analysing crashes in $CRASH_DIR..."
for crash_file in "$CRASH_DIR"/id:*; do
[ -e "$crash_file" ] || continue
echo "--------------------------------------------------" >>"$OUTPUT_LOG"
echo "File: $(basename "$crash_file")" >>"$OUTPUT_LOG"
gdb --batch \
--ex "run" \
--ex "bt" \
--ex "quit" \
--args "$TARGET" "$crash_file" >>"$OUTPUT_LOG" 2>&1
echo -e "\n" >>"$OUTPUT_LOG"
done
echo "[+] Done! Result in: $OUTPUT_LOG"

Analysis#

这个项目有 API 文档,不用自己猜函数功能了:libexif Project Documentation.

好的,继续玩 MC,快开学了,谁学啊!?

CVE-2012-2836#

先分析一下这个样本,栈回溯如下:

#0 0x00007ffff7e595c1 in memcpy () from /usr/lib64/libc.so.6
#1 0x0000555555565553 in exif_data_load_data_thumbnail (data=0x5555555931e0, d=0x555555595986 "II*", ds=256, offset=4294967168, size=232) at exif-data.c:292
#2 0x0000555555563d05 in exif_data_load_data_content (data=0x5555555931e0, ifd=EXIF_IFD_EXIF, d=0x555555595986 "II*", ds=256, offset=86, recursion_depth=1) at exif-data.c:381
#3 0x0000555555563b36 in exif_data_load_data_content (data=0x5555555931e0, ifd=EXIF_IFD_0, d=0x555555595986 "II*", ds=256, offset=10, recursion_depth=0) at exif-data.c:361
#4 0x0000555555563621 in exif_data_load_data (data=0x5555555931e0, d_orig=0x555555595980 "Exif", ds_orig=262) at exif-data.c:813
#5 0x000055555556cb9b in exif_loader_get_data (loader=0x555555593190) at exif-loader.c:387
#6 0x000055555555f73e in main (argc=2, argv=0x7fffffffdca8) at main.c:438

exif_loader_get_data 负责为 ExifData 结构体开辟空间,然后使用 exif_data_load_data 将内存中的 JPEG / EXIF header, byte order, fixed value 等信息加载到 ExifData 结构体中,进行一些简单的校验,并初始化 IFD 0IFD 1。初始化 IFD 字段是通过调用 exif_data_load_data_content 实现的。

根据这个 switch 就可以看出来,很显然,load data content 大致应该就是将 exif 图片的各个字段信息加载进去。

继续调试,我们在 EXIF_TAG_EXIF_IFD_POINTER 这个 case 调用了 exif_data_load_data_content,此时传入的 ifd 为 EXIF_IFD_EXIF,而我们后续也是在这里面执行 exif_data_load_data_thumbnail 时崩溃的,所以要重点分析一下这部分。

首先确定一下在第几次循环的时候崩溃,我们直接 c 让它崩,然后切换到对应栈帧查看 i,发现是第 13 次调用了 exif_data_load_data_thumbnail

然后通过 if i == 13 下条件断点,定位到触发崩溃的循环索引继续分析。由于这里有两个调用 exif_data_load_data_thumbnail 的位置,而我们不知道具体会调用哪一个,因此如果我们下的那个断点不是实际的调用点,那就停不下来了。所以这里两个位置都需要下一个断点:

最后我们发现它执行的是 381 行处的代码,整洁起见,之前 374 行处的断点就可以删掉了。

步入继续,发现致使 memcpy 崩溃的原因是 rsi 无法解引用:

接下来重点看这个 exif_data_load_data_thumbnail 的逻辑:

// ► 0x555555563d00 <exif_data_load_data_content+1168> call exif_data_load_data_thumbnail <exif_data_load_data_thumbnail>
// rdi: 0x555555593240 —▸ 0x5555555932d0 —▸ 0x5555555934a0 —▸ 0x555555593420 ◂— 0x200000110
// rsi: 0x555555595986 ◂— 0x8002a4949 /* 'II*' */
// rdx: 0x100
// rcx: 0xffffff80
// r8: 0xe8
static void
exif_data_load_data_thumbnail (ExifData *data, const unsigned char *d,
unsigned int ds, ExifLong offset, ExifLong size)
{
if (ds < offset + size) {
exif_log (data->priv->log, EXIF_LOG_CODE_DEBUG, "ExifData",
"Bogus thumbnail offset and size: %i < %i + %i.",
(int) ds, (int) offset, (int) size);
return;
}
if (data->data)
exif_mem_free (data->priv->mem, data->data);
data->size = size;
data->data = exif_data_alloc (data, data->size);
if (!data->data)
return;
memcpy (data->data, d + offset, data->size);
}

通过调试,我们可知它根本不会进入那三个 if branch,也就是说,这个函数只执行了如下三行代码:

data->size = size;
data->data = exif_data_alloc (data, data->size);
memcpy (data->data, d + offset, data->size);

即将 size 设置为 r8,将 data 设置为 exif_data_alloc 分配出来的值,而 src 则是 d + offset 的值,即 rsi + 0xffffff80

显然,这个 offset 特别大,而经调试,我们的 rsi 其实是合法值,那么问题就处在 offset 上了。

回溯发现,在给 exif_data_load_data_thumbnail 传参时,offset 的值就有问题了:

通过查看二进制数据,我们很容易定位到一个类似的数据:

尝试直接将其修改为 0xCAFEBABE,然后再调试一下。调试之前我们可以先使用 save breakpoints bps 将断点信息保存到 bps 文件,之后通过 source bps 加载。

可见,我们可以通过控制图片的内部数据信息来控制 memcpy 的行为,至于具体怎么利用,利用后有什么效果,我就不分析了。直接确定一下 CVE ID,发现这个 CVE-2012-2836 的描述比较符合我们的分析结果。

CVE-2009-3895#

Program received signal SIGSEGV, Segmentation fault.
0x000055555556e60f in exif_get_slong (b=0x5555555b2000 <error: Cannot access memory at address 0x5555555b2000>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:129
129 return ((b[3] << 24) | (b[2] << 16) | (b[1] << 8) | b[0]);
#0 0x000055555556e60f in exif_get_slong (b=0x5555555b2000 <error: Cannot access memory at address 0x5555555b2000>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:129
#1 0x000055555556e49f in exif_get_long (buf=0x5555555b2000 <error: Cannot access memory at address 0x5555555b2000>, order=EXIF_BYTE_ORDER_INTEL) at exif-utils.c:156
#2 0x0000555555566026 in exif_entry_fix (e=0x555555593460) at exif-entry.c:189
#3 0x0000555555562d6d in fix_func (e=0x555555593460, data=0x0) at exif-content.c:211
#4 0x0000555555562a13 in exif_content_foreach_entry (content=0x555555593270, func=0x555555562d50 <fix_func>, data=0x0) at exif-content.c:185
#5 0x0000555555562bdc in exif_content_fix (c=0x555555593270) at exif-content.c:225
#6 0x0000555555565481 in fix_func (c=0x555555593270, data=0x0) at exif-data.c:1082
#7 0x00005555555650ca in exif_data_foreach_content (data=0x5555555931e0, func=0x5555555653e0 <fix_func>, user_data=0x0) at exif-data.c:965
#8 0x00005555555643d4 in exif_data_fix (d=0x5555555931e0) at exif-data.c:1087
#9 0x0000555555563886 in exif_data_load_data (data=0x5555555931e0, d_orig=0x555555595980 "", ds_orig=82) at exif-data.c:826
#10 0x000055555556cbeb in exif_loader_get_data (loader=0x555555593190) at exif-loader.c:368
#11 0x000055555555f75e in main (argc=2, argv=0x7fffffffdbe8) at main.c:438

直接调,调就完了。

一开始都是差不多的,exif_data_fix 的作用是将不符合规格的 exif 数据修复,使其符合规范,内部其实就是对 exif_data_foreach_content 的包装,而 exif_data_foreach_content 则是对每一个 IFD 执行指定的函数,这里是 fix_func ……

其实我觉得没必要从 main 开始分析,直接从崩溃边界开始分析就好了,所以接下来我会从后往前分析。

可以看到,是 rax 无法解引用导致的问题。入口是 exif_entry_fix 之后的 exif_get_long

回溯到调用 exif_get_long 的函数 exif_entry_fix

我们发现这里是一个 for 循环,并且此时的索引是 31440,巨大无比,显然不正常,而索引范围是 e->components 指定的:

这都十亿多次了,所以问题就是没有验证这个 component 大小的合法性。此外,这个大小也是攻击者可控的:

components 肯定代表了组件数量,什么东西的组件数量?翻代码,发现是 ExifEntry

通过查询 exif 标准 1 我们可知,一个 ExifEntryFormatComponentsData 组成。如果 format 类型是 unsigned short,则它代表每个 component 占用 2 bytes,而 components 则代表了这样的组件有几个,将它和 format 相乘即是这一 entry 总共占用的字节数。

所以这里的问题显然就是 e->components 很大,而 e->data 分配的内存很小,导致 OOB 。而在计算 e->size = e->components * exif_format_get_size(e->format) 时,如果 components 特别大也有可能发生溢出,导致最后得到一个特别小的值。如果后续用这个特别小的 size 去申请内存,就会有申请大小远小于实际需求的问题,写入将直接崩溃或允许执行任意代码。

定位一下 CVE,发现符合 CVE-2009-3895 的描述。至此,这个 chall 要求的两个 CVE 我们均已找齐,剩下那几个 crashes 和 hang 我就不分析了,懒(

Fix#

CVE-2012-2836#

调试发现,这个非法 offset 来自 exif_get_long 函数,我们深入分析一下它的逻辑。

首先调用入口是:

case EXIF_TAG_JPEG_INTERCHANGE_FORMAT:
o = exif_get_long (d + offset + 12 * i + 8,
data->priv->order);

所以它是取 d + offset + 12 * i + 8 这个偏移处的值。查阅文档,我们可知它就是返回一个 uint32_t 类型,而它内部使用的 exif_get_slong 会返回一个 int32_t 类型:

ExifLong
exif_get_long (const unsigned char *buf, ExifByteOrder order)
{
return (exif_get_slong (buf, order) & 0xffffffff);
}
ExifSLong
exif_get_slong (const unsigned char *b, ExifByteOrder order)
{
if (!b) return 0;
switch (order) {
case EXIF_BYTE_ORDER_MOTOROLA:
return ((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3]);
case EXIF_BYTE_ORDER_INTEL:
return ((b[3] << 24) | (b[2] << 16) | (b[1] << 8) | b[0]);
}
/* Won't be reached */
return (0);
}

虽然通过 & 0xffffffff 截断处理了整数溢出问题,但是 0xffffffff 依旧可以表示一个巨大的范围,大概 4 GB?所以问题就在于,它没检查偏移是否合理。

解决方法很简单,只要将 offset 限制在 ds 的范围内即可。ds 代表了 data size, 也就是整个图像数据的大小边界。超过 ds 肯定是不对的。

exif-data.c
case EXIF_TAG_JPEG_INTERCHANGE_FORMAT:
o = exif_get_long(d + offset + 12 * i + 8, data->priv->order);
if (o >= ds) {
exif_log(data->priv->log, EXIF_LOG_CODE_CORRUPT_DATA, "ExifData",
"Illegal offset value detected!");
abort();
}

CVE-2009-3895#

分析的时候已经写过问题了,修复方法就是校验 components 与当前 size 是否匹配:

exif-entry.c
case EXIF_TAG_SHARPNESS:
switch (e->format) {
case EXIF_FORMAT_LONG:
if (!e->parent || !e->parent->parent)
break;
if (e->components <= 0 || e->components > 65535) {
exif_entry_log(e, EXIF_LOG_CODE_CORRUPT_DATA,
"Component size is too large!");
abort();
}
if (e->size < e->components * exif_format_get_size(EXIF_FORMAT_LONG)) {
exif_entry_log(e, EXIF_LOG_CODE_CORRUPT_DATA,
"Corrupted data size detected!");
abort();
};
o = exif_data_get_byte_order(e->parent->parent);
for (i = 0; i < e->components; i++)
exif_set_short(
e->data + i * exif_format_get_size(EXIF_FORMAT_SHORT), o,
(ExifShort)exif_get_long(
e->data + i * exif_format_get_size(EXIF_FORMAT_LONG), o));
e->format = EXIF_FORMAT_SHORT;
e->size = e->components * exif_format_get_size(e->format);
e->data = exif_entry_realloc(e, e->data, e->size);
exif_entry_log(e, EXIF_LOG_CODE_DEBUG,
_("Tag '%s' was of format '%s' (which is "
"against specification) and has been "
"changed to format '%s'."),
exif_tag_get_name(e->tag),
exif_format_get_name(EXIF_FORMAT_LONG),
exif_format_get_name(EXIF_FORMAT_SHORT));
break;

成功修复:

但是发现 rational 类型也有问题,不过直接使用和上面一样的 patch 方案就能解决。

case EXIF_TAG_FOCAL_LENGTH:
switch (e->format) {
case EXIF_FORMAT_SRATIONAL:
if (!e->parent || !e->parent->parent)
break;
if (e->components <= 0 || e->components > 65535) {
exif_entry_log(e, EXIF_LOG_CODE_CORRUPT_DATA,
"Component size is too large!");
abort();
}
if (e->size < e->components * exif_format_get_size(EXIF_FORMAT_LONG)) {
exif_entry_log(e, EXIF_LOG_CODE_CORRUPT_DATA,
"Corrupted data size detected!");
abort();
};
o = exif_data_get_byte_order(e->parent->parent);
for (i = 0; i < e->components; i++) {
sr = exif_get_srational(
e->data + i * exif_format_get_size(EXIF_FORMAT_SRATIONAL), o);
r.numerator = (ExifLong)sr.numerator;
r.denominator = (ExifLong)sr.denominator;
exif_set_rational(
e->data + i * exif_format_get_size(EXIF_FORMAT_RATIONAL), o, r);
}
e->format = EXIF_FORMAT_RATIONAL;
exif_entry_log(e, EXIF_LOG_CODE_DEBUG,
_("Tag '%s' was of format '%s' (which is "
"against specification) and has been "
"changed to format '%s'."),
exif_tag_get_name(e->tag),
exif_format_get_name(EXIF_FORMAT_SRATIONAL),
exif_format_get_name(EXIF_FORMAT_RATIONAL));
break;

也算是在开学前完成了这两个 CVE 的复现,还没懒到啥也不干……

References#

Footnotes#

  1. Description of Exif file format

Fuzz two legacy CVEs in libexif
https://cubeyond.net/posts/fuzz/libexif/
Author
CuB3y0nd
Published at
2026-02-24
License
CC BY-NC-SA 4.0