Decompression of LZMA streams may fail if the input stream is too slow #1009

New issue

Open

opened 2025-10-11 14:25:49 +00:00 by raito · 1 comment

raito commented

2025-10-11 14:25:49 +00:00

Owner

If the input LZMA stream is split / arriving too slowly, the libarchive processing machinery might receive from the LZMA code an LZMA_BUF_ERROR:

LZMA_BUF_ERROR 	

No progress is possible.

This error code is returned when the coder cannot consume any new input and produce any new output. The most common reason for this error is that the input stream being decoded is truncated or corrupt.

This error is not fatal. Coding can be continued normally by providing more input and/or more output space, if possible.

libarchive code does not recover from this error and seems to be considering it fatal, bubbling into Lix as "failed to read compression data: No progress can be made".

Solutions includes:

create a test case to reproduce this out of "sheer luck" (which seems to be related
patching libarchive
using Rust-ified archived libraries as long as the integration work is not too expensive

(Credits where it's due: all the investigative work has been done by @pennae)

If the input LZMA stream is split / arriving too slowly, the libarchive processing machinery might receive from the LZMA code an `LZMA_BUF_ERROR`: ``` LZMA_BUF_ERROR No progress is possible. This error code is returned when the coder cannot consume any new input and produce any new output. The most common reason for this error is that the input stream being decoded is truncated or corrupt. This error is not fatal. Coding can be continued normally by providing more input and/or more output space, if possible. ``` [libarchive code does not recover from this error and seems to be considering it fatal](https://github.com/libarchive/libarchive/blob/master/libarchive/archive_read_support_filter_xz.c#L704), bubbling into Lix as "failed to read compression data: No progress can be made". Solutions includes: - create a test case to reproduce this out of "sheer luck" (which seems to be related - patching libarchive - using Rust-ified archived libraries as long as the integration work is not too expensive (Credits where it's due: all the investigative work has been done by @pennae)

raito added the

labels

2025-10-11 14:26:16 +00:00

raito added the

release-blocker

label

2025-10-13 10:35:46 +00:00

raito commented

2025-10-13 12:12:58 +00:00

Author

Owner

Work done by @yu-re-ka seems to indicate this is caused by a bump in our dependencies:

commit 15ed8f7638116135ac9d3bd4353c482e7c539e0f
Merge: ee5dae584d75 17eefed8a027
Author: Vladimír Čunát <v@cunat.cz>
Date:   Sun Oct 5 13:28:34 2025 +0000

    staging-next 2025-09-21 (#444862)

Work done by @yu-re-ka seems to indicate this is caused by a bump in our dependencies: ``` commit 15ed8f7638116135ac9d3bd4353c482e7c539e0f Merge: ee5dae584d75 17eefed8a027 Author: Vladimír Čunát <v@cunat.cz> Date: Sun Oct 5 13:28:34 2025 +0000 staging-next 2025-09-21 (#444862) ```