bzip2 contains an off‑by‑one error in the bzip2recover utility. When processing a specially crafted file, the application performs an out‑of‑bounds write to a global buffer, resulting in memory corruption and a crash (denial of service).

On Wed, Aug 13, 2025 at 07:00:58PM +0200, Vincent Lefevre wrote: The following makes the xterm terminal crash

touch "$(printf "file\e[H\e[c\n\b")" gunzip file

due to malicious character sequences in the file name and a bug in xterm. Same issue with bunzip2 instead of gunzip.

Note that in practice, such a file name is not necessarily created by the end user who runs gunzip. It may come from a downloaded archive or from another user on a shared machine.

Is this regarded as a vulnerability, in particular due to the loss of the shell session and associated data (which cannot be recovered)? Vincent omitted his custom configuration (reverseWrap), which affects the number of users affected. Which is or are the culprit(s)? xterm itself (note that it is also possible to make some recent xterm versions crash without these usual escape sequences); gzip and bzip2, which should sanitize the output to the terminal (like many other utilities already do nowadays); the file system, which should not allow the creation of such file names (I don't know what POSIX says exactly)?

FYI, I've just reported bugs:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79231 for gzip https://sourceware.org/bugzilla/showbug.cgi?id=33276 for bzip2

(I had also reported 2 bugs against xterm related to its crash in the Debian BTS.) Dereferencing a null pointer:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110769

(no buffer overflows, etc).

-- Thomas E. Dickey <dickey () invisible-island net> https://invisible-island.net

BZ2decompress in decompress.c in bzip2 through 1.0.6 has an out-of-bounds write when there are many selectors.

Reference: https://gitlab.com/federicomenaquintero/bzip2/commit/74de1e2e6ffc9d51ef9824db71a8ffee5962cdbc

Aladdin Mubaied discovered that bzip2 incorrectly handled certain files. An attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 16.04 LTS. (CVE-2016-3189) It was discovered that bzip2 incorrectly handled certain files. An attacker could possibly use this issue to execute arbitrary code. (CVE-2019-12900)

USN-4038-1 fixed several vulnerabilities in bzip2. This update provides the corresponding update for Ubuntu 12.04 ESM and Ubuntu 14.04 ESM. Original advisory details: Aladdin Mubaied discovered that bzip2 incorrectly handled certain files. An attacker could possibly use this issue to cause a denial of service. (CVE-2016-3189) It was discovered that bzip2 incorrectly handled certain files. An attacker could possibly use this issue to execute arbitrary code. (CVE-2019-12900)

A heap use after free vulnerability was reported in bzip2recover. A maliciously crafted file could cause the application to crash.

Proposed patch attached.

== ASAN output & backtrace == bzip2recover 1.0.6: extracts blocks from damaged .bz2 files. /opt/bzip-asan/bin/bzip2recover: searching for block boundaries ... block 1 runs from 176 to 175 block 2 runs from 224 to 871 block 3 runs from 920 to 919 block 4 runs from 968 to 1024 (incomplete) bzip2recover: splitting into blocks writing block 2 to crasherfile1' ... Program received signal SIGSEGV, Segmentation fault. ================================================================= ==8476== ERROR: AddressSanitizer: heap-use-after-free on address 0x60060000ef8c at pc 0x40277c bp 0x7fff7f1afe90 sp 0x7fff7f1afe80 READ of size 4 at 0x60060000ef8c thread T0 #0 0x40277b (/opt/bzip-asan/bin/bzip2recover+0x40277b) #1 0x401f35 (/opt/bzip-asan/bin/bzip2recover+0x401f35) #2 0x7f10fcae2af4 (/usr/lib64/libc-2.17.so+0x21af4) #3 0x4020e4 (/opt/bzip-asan/bin/bzip2recover+0x4020e4) 0x60060000ef8c is located 12 bytes inside of 24-byte region [0x60060000ef80,0x60060000ef98) freed by thread T0 here: #0 0x7f10fce98009 (/usr/lib64/libasan.so.0.0.0+0x16009) #1 0x40205c (/opt/bzip-asan/bin/bzip2recover+0x40205c) previously allocated by thread T0 here: #0 0x7f10fce98129 (/usr/lib64/libasan.so.0.0.0+0x16129) #1 0x40175f (/opt/bzip-asan/bin/bzip2recover+0x40175f) Shadow bytes around the buggy address: 0x0c013fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c013fff9df0: fd[fd]fd fa fa fa 00 00 00 fa fa fa fd fd fd fa 0x0c013fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe

bt #0 0x00007ffff7a8fa11 in putc () from /lib64/libc.so.6 #1 0x00000000004046ad in bsPutBit (bit=0x0, bs=<optimized out>) at bzip2recover.c:183 #2 bsPutUChar (c=<optimized out>, bs=<optimized out>) at bzip2recover.c:246 #3 main (argc=<optimized out>, argv=<optimized out>) at bzip2recover.c:455 #4 0x00007ffff7a3caf5 in libcstartmain () from /lib64/libc.so.6 #5 0x0000000000405bd9 in start ()