[sword-devel] Segfault in LZSS code

[Troy A. Griffitts]

While I agree we probably shouldn't segfault, this is a bit like
renaming xyz.exe to xyz.doc and trying to open it in Word.

Not that is matters, but the details are that the LZSS decompressor
treats the entire block as uncompressed binary (because it doesn't
encounter any compression block signatures, because the data is not LZSS
data but instead ZIP encoded data) and does nothing with any of it,
returning the zip compressed data as-is, resulting in binary gibberish
when we reference it, so when we pull offset and size values from the
"uncompressed" block (which really isn't uncompressed), we get
essentially random numbers... which causes things to crash.  Not sure
what Word does when you give it a ".doc" file which is a binary, or
MySQL does when you cat /dev/random > /var/data/mysql/ibdata1, but I
would bet it doesn't behave very well.

I would say the solution to this is don't give the LZSS filters ZIP
compressed data.  I can try to put some sanity checks in when I read the
offset, size values from the "uncompressed" data and might be able to
prevent a crash.

Troy


On 2/27/21 10:19 AM, Bastian Germann wrote:
> Am 27.02.21 um 17:47 schrieb refdoc at gmx.net:
>> Could you put a bug report into JIRA?
>
> https://tracker.crosswire.org/browse/API-247
>
>> As such the LZSS code is experimental and should not be relied upon.
>>
>
> Why is it the default then? (according to
> https://wiki.crosswire.org/DevTools:conf_Files#Required_Elements_with_defaults)
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page