As per the following analysis by Thomas Schmitt, who investigated an error
report reported against libcdio when trying to process
openSUSE-Leap-15.0-DVD-x86_64.iso:
http://lists.gnu.org/archive/html/libcdio-devel/2018-05/msg00008.html

Specifically:

ECMA-119, 7.3.3 "Both-byte orders" and 9.1.4 "Data Length (BP11 to BP18)"
prescribe that the byte count of a data file is to be recorded as first a
little-endian 32-bit number and then a big-endian 32-bit number.

However, Kiwi only appears to patch the little-endian bytes into the ISO when
it sets the final size of the affected files.

For instance, you can find a file in openSUSE-Leap-15.0 that bears as size:

  e1  01  00  00  00  00  08  00

where the first four bytes are correct and the next four are wrong.

This is probably because only the first four were overwritten by Kiwi, when it
patched in the new size after manipulating the file content.

Therefore, independently of a separate libcdio issue (which should gracefully
warn when it finds such an inconsistency, rather than bail out), there is a
definite problem with the way Kiwi updates the file sizes, as only seems to do
half the job, which is in breach of the ECMA specs.

Hopefully this specs compliance issue can be fixed for future releases of
openSUSE.