Bug#1021062: libc6: nonexistent locale crashes programs (for example, bash, gdb, ...)
control: reassign -1 bash
control: found -1 bash/5.2-1
Hi,
On 2022-10-01 21:01, Kan-Ru Chen wrote:
> Package: libc6
> Version: 2.35-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: koster@debian.org
>
> Dear maintainer,
>
> After upgrading to libc6 2.35-1 (or 2.36-1 in experimental), nonexistent locale setting
> starts to crash the system.
>
> This is dangerous because a remote system might not always have the same locale installed.
> An auto update will soft-brick the system unless the sysadmin knows to set their LC_ALL=POSIX
> before attempting to ssh.
>
> Steps to reproduce:
>
> >From a clean installed Debian sid, upgrade to libc6 2.35-1.
> Only install C locale and en_US.UTF-8.
>
> $ LC_ALL=ja_JP.UTF-8 bash
> bash: warning: setlocale: LC_ALL: cannot change locale (ja_JP.UTF-8)
> Segmentation fault (core dumped)
>
> $ LC_ALL=ja_JP.UTF-8 gdb bash
>
> Fatal signal: Segmentation fault
> ----- Backtrace -----
> 0x55ed3e1e8dcf ???
> 0x55ed3e2df312 ???
> 0x55ed3e2df488 ???
> 0x7f0b4a39ba9f ???
> 0x7f0b4b412204 _rl_init_locale
> 0x7f0b4b4122f1 _rl_init_eightbit
> 0x7f0b4b3f10f2 rl_initialize
> ... snip ...
FYI, this is the full backtrace with the debug packages installed:
#0 0x00007f8079d0ccc7 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
#1 0x0000559be26519c9 in termsig_handler (sig=11) at .././sig.c:625
#2 0x0000559be2651c21 in termsig_handler (sig=<optimized out>) at .././sig.c:492
#3 termsig_sighandler (sig=<optimized out>) at .././sig.c:547
#4 <signal handler called>
#5 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
#6 0x0000559be26b8682 in _rl_init_locale () at ../../.././lib/readline/nls.c:150
#7 0x0000559be26b8772 in _rl_init_eightbit () at ../../.././lib/readline/nls.c:227
#8 0x0000559be269766e in readline_initialize_everything () at ../../.././lib/readline/readline.c:1292
#9 rl_initialize () at ../../.././lib/readline/readline.c:1183
#10 0x0000559be2662b05 in initialize_readline () at .././bashline.c:522
#11 0x0000559be26040a5 in yy_readline_get () at /usr/local/src/chet/src/bash/src/parse.y:1514
#12 0x0000559be2606aa1 in yy_getc () at /usr/local/src/chet/src/bash/src/parse.y:1462
#13 shell_getc (remove_quoted_newline=remove_quoted_newline@entry=1) at /usr/local/src/chet/src/bash/src/parse.y:2393
#14 0x0000559be2608eeb in read_token (command=0) at /usr/local/src/chet/src/bash/src/parse.y:3400
#15 0x0000559be260d05b in yylex () at /usr/local/src/chet/src/bash/src/parse.y:2890
#16 yyparse () at ./build-bash/y.tab.c:1854
#17 0x0000559be2603586 in parse_command () at .././eval.c:348
#18 0x0000559be2603714 in read_command () at .././eval.c:392
#19 0x0000559be26038c6 in reader_loop () at .././eval.c:139
#20 0x0000559be26023b5 in main (argc=1, argv=0x7ffe3da22078, env=0x7ffe3da22088) at .././shell.c:833
So the problem is that _rl_init_locale (from bash) calls strlen(NULL).
> Downgrade to 2.34-8 seems also don't fix the issue, probably some locale
> state was invalidated when upgrading.
This is because you upgraded other packages than glibc (here bash), and the bug
is not in glibc. Downgrading bash fixes the issue. Reassigning the bug.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: