A crafted bz3 archive hangs the process

[asarubbo]

Hello,

the attached testcase is able to hang the process:

~ # ps aux | grep bzip3 | grep -v grep
root     36808  100  0.0 21474991596 74724 pts/0 R+ 08:49  14:07 /usr/bin/bzip3 -t 4.crashes.bz3

~ # ps -eo pid,etimes | grep 36808
36808     852

I can reproduce the issue on both v1.2.2 and v1.2.2.r21-ge17c8da (https://github.com/kspalaiologos/bzip3/commit/e17c8daf5b87d63a1aba376cae80718372d3fbda)

I can also reproduce with a binary not compiled with Asan.

To reproduce:

bzip3 -t $TESTCASE

Testcase: 4.crashes.bz3.zip

[kspalaiologos]

Will take a look later.

[kspalaiologos]

Hangs in libsais_unbwt_decode_1. Won't fix. When reporting future issues please make sure that you're reporting a problem with bzip3, not libsais.

[asarubbo]

Based on the statement here https://github.com/IlyaGrebnov/libsais/issues/13#issuecomment-1483950007 can you clarify if this is an issue in bzip3 and if https://github.com/kspalaiologos/bzip3/commit/bfa5bf82b53715dfedf048e5859a46cf248668ff is the fix?

[kspalaiologos]

Yes. There was an extra I/O issue that needed addressing in 56c24ca.

[stevebeattie]

This issue was assigned CVE-2023-29415.

(I did not assign the CVE, I just noticed it while triaging new CVEs.)

[kspalaiologos]

@stevebeattie The CVE description is just plain wrong:

because bzip3 does not follow the required procedure for interacting with libsais.

The libsais documentation never states that it expects a zeroed temporary array.

[stevebeattie]

I agree. Looking at the (bottom of the) NVD page it seems it was allocated by MITRE, likely from a submission through their webform. You can request to update the description through the same form (though as a piece of advice, keep a record for yourself of what you send them as their ticketing response does not send you a copy of what you submitted, and there can be a delay on when they respond to you).

[kspalaiologos]

https://www.cve.org/CVERecord?id=CVE-2023-29417 is also hilarious to me, as bz3_decompress takes the output buffer as parameter and its capacity meaning that obviously when you claim that the buffer you passed has greater capacity than it actually has, the library is going to crash. Of course, you could open such a bug against e.g. glibc because memcpy will keep copying past the end of buffer when the size you passed to it is bogus.

Because it appears to me that these two CVEs were filed with more attention seeking and less reasonable thinking, I think that I will not bother to ask for them to be updated, because everyone who knows C to some extent and bothers to read libsais documentation will know that they're plain invalid.