ABI break in 0.19.3 is causing crashes in existing users of libraw.so.19

[vanvugt]

ABI break in 0.19.3 is causing crashes in existing users of libraw.so.19

Because those existing users will new LibRaw with the old size, and then the new LibRaw 0.19.3 will overrun it when trying to assign field metadata_blocks, corrupting the heap.

Downstream: https://bugs.launchpad.net/bugs/1838387

[LibRaw]

Yes, this is noted in Changelog.

Unfortunately, there is no way to prevent CRW parsing loops w/o implementing additional count field.....

[vanvugt]

Alright, well just be aware that breaking an ABI without changing the soname of the library will cause crashes in projects using that library. Ideally ABI breaks should only occur on the master branch and not on branches with "stable" in their name, like 0.19-stable.

I guess by logging this bug I was hoping for a version 0.19.4 that would be ABI-compatible with 0.19.2, and we could skip 0.19.3 in Ubuntu and others. If that's not doable then feel free to just close this bug.

[LibRaw]

The only way is to revert back CRW loop prevention in 0.19
This problem is NOT related to normal files, but possible on specially crafted ones.

[vanvugt]

Or to rearrange private members such that the object size is unchanged compared to 0.19.2. That can sometimes be done by finding alignment padding holes in the structure and filling them, or by replacing large integer types with smaller ones, or by shrinking internal arrays to make room.

Obviously it's your project so you can do what you like, and doing nothing is also an option. I'm not realistically expecting a fix, only fishing for one because it would make Ubuntu/Debian's life easier 🙂

[LibRaw]

Skip CRW loop patch in 0.19 (e.g. under #ifdef) is a good idea. In most real cases, users do not feed unknown files to LibRaw, so not affected by this problem.

Structure packing change may result in other unexpecteded problems, no way to check it from our side.

[vanvugt]

The way to check that structure packing is working is to compare sizeof(LibRaw) between versions (note i386 builds encountered the problem first, not amd64).

Also I was only talking about modifying private members, so as to guarantee that other unexpected problems are minimised. I'm not sure that's even possible in this case.

So if you can drop the loop patch in 0.19.4 that would be much appreciated. It would then mean all allocations of LibRaw objects are large enough to accomodate all the memory accesses, and no memory overruns.

[LibRaw]

Could you please check this commit: 7106e3f

This is not final 0.19.4 b/c we have several not-finished bug reports for it, but it is vital to know that commenting out LibRaw::metatada_blocks member solves crash problem.

[vanvugt]

Thanks. Verified 7106e3f has fixed the crash. ✔️

[LibRaw]

great.
We'll publish 0.18.4 in a few days (with this fix).

[vanvugt]

You mean 0.19.4? 🙂

[LibRaw]

working on it, sorry, takes longer than expected.

[LibRaw]

(sorry, wrong button, it is not closed yet)

[LibRaw]

0.19.4 is here: https://github.com/LibRaw/LibRaw/tree/0.19-stable
and also here: https://www.libraw.org/news/libraw-0-19-4-release

(delay was caused by SRF metatada parser fixes, but this parser is not in 0.19, so 0.19.4 do not need to wait for SRF parser fixes)