[Pkg-libburnia-devel] Bug#872590: libisofs6: integer overflow in susp_iter_next()

[Thomas Schmitt]

Hi,

this is not so eay to fix. Lots of potential holes for the rabbit
to sneak in.

A big problem is this plan of my predecessor developer in libisofs:
            /* read all blocks needed to cache the full CE */

The continuation area is allowed to be up to 4 GiB of size.
iter->ce_off is the uint32_t byte offset in that area.
iter->ce_len is the uint32_t number of bytes which belong to the
current file's area within the big shared CE area.

This prevents me from flatly refusing on oversized nblocks values.
Even in regular situations it would be possible that a CE area has
dozens of MiB, because it consolidates SUSP data from many files.

So i will have to change this to only reading of the file's CE blocks.
This might have consequences in other parts of the code.


Next problem is that class SuspIterator knows of the imported ISO
only the aspect of class IsoDataSource, which cannot yet tell the
number of its valid blocks.
Without this info i cannot judge the validity of a read address
before trying to read it. Depending on the medium, a read operation
might succeed even if the block is outside the ISO filesystem size.


Both problems are not unfixable. But the fixes affect other code
parts. Changing the API class IsoDataSource would not solve the problem
because then i would have to keep the older dumb version valid for
API/ABI compatibility.

I shall not forget the risk of regressions which rises when small
holes get fixed by big band-aids. See libcdio's
  https://savannah.gnu.org/bugs/?45015
where the heavy-handed fix of an AFL-found bug caused that all Rock Ridge
info was ignored in ISOs with AAIP entry AL.


So this might last a while.


Have a nice day :)

Thomas