Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
I can confirm updating the microcode by installing the intel-microcode package and rebooting does indeed mitigate this issue. An LXC container that was previously bricked due to update now starts and seems to behave fully normally. [0.00] microcode: microcode updated early to revision 0x28, date = 2019-11-12 But as microcode update needs to be loaded every time on boot (unless I presumably updated the UEFI), while it technically solves my problem on this installation, the concern of people with the same family of processors and outdated microcode running into this issue and having no idea why any Linux does not want to boot anymore still probably remains... (is there even any easy way to load updated microcode while installing Debian? I can most certainly bet its ISO does not include those due to non-free constraints)
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hello, sorry for delayed response, I've managed to collect and analyze a few coredump files with valid symbols (I installed libc6-dbg and dpkg-dev, and pointed gdb at Debian's debuginfod server, also used apt-get source to get the sources for libc6). It seems there are at least 3-4 distinct places it crashes at, two places at memchr-avx2.S, one at strlen-avx2.S, and potentially one at syscall-template.S, although that last one may be just some kind of kill signal redirect. Pasting all below: Core was generated by `apt'. Program terminated with signal SIGILL, Illegal instruction. #0 __memchr_avx2 () at ../sysdeps/x86_64/multiarch/memchr-avx2.S:400 Download failed: Invalid argument. Continuing without source file ./string/../sysdeps/x86_64/multiarch/memchr-avx2.S. 400 ../sysdeps/x86_64/multiarch/memchr-avx2.S: No such file or directory. (gdb) ### Core was generated by `dpkg'. Program terminated with signal SIGILL, Illegal instruction. #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:514 Download failed: Invalid argument. Continuing without source file ./string/../sysdeps/x86_64/multiarch/strlen-avx2.S. 514 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory. (gdb) ### Core was generated by `/usr/bin/perl /usr/sbin/adduser'. Program terminated with signal SIGILL, Illegal instruction. #0 __memchr_avx2 () at ../sysdeps/x86_64/multiarch/memchr-avx2.S:135 Download failed: Invalid argument. Continuing without source file ./string/../sysdeps/x86_64/multiarch/memchr-avx2.S. 135 ../sysdeps/x86_64/multiarch/memchr-avx2.S: No such file or directory. (gdb) ### Core was generated by `useradd'. Program terminated with signal SIGILL, Illegal instruction. #0 __memchr_avx2 () at ../sysdeps/x86_64/multiarch/memchr-avx2.S:135 Download failed: Invalid argument. Continuing without source file ./string/../sysdeps/x86_64/multiarch/memchr-avx2.S. 135 ../sysdeps/x86_64/multiarch/memchr-avx2.S: No such file or directory. (gdb) ### Core was generated by `passwd'. Program terminated with signal SIGILL, Illegal instruction. #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:514 Download failed: Invalid argument. Continuing without source file ./string/../sysdeps/x86_64/multiarch/strlen-avx2.S. 514 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory. (gdb) ### Core was generated by `bash'. Program terminated with signal SIGILL, Illegal instruction. #0 0x7f2006faf087 in kill () at ../sysdeps/unix/syscall-template.S:120 Download failed: Invalid argument. Continuing without source file ./signal/../sysdeps/unix/syscall-template.S. 120 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) ### Core was generated by `su'. Program terminated with signal SIGILL, Illegal instruction. #0 __memchr_avx2 () at ../sysdeps/x86_64/multiarch/memchr-avx2.S:135 Download failed: Invalid argument. Continuing without source file ./string/../sysdeps/x86_64/multiarch/memchr-avx2.S. 135 ../sysdeps/x86_64/multiarch/memchr-avx2.S: No such file or directory. (gdb) ### It does seem in case of this SIGILL there's no additional stack trace, also the path containing ".." seems to cause the source code resolution to fail, but still the debug symbols seem to show the file source and line, so it should hopefully help see what exactly fails. I'm yet to try rebooting with microcode package installed though (I'll soon check it and update on whether it helps, but even if it does, one without bootable system first won't get a chance to install it; I'm a bit curious how these changes did trigger this, given all these years it didn't happen to occur before)
Bug#1020654: C.UTF-8: surprising differences in character classes
Package: locales
Version: 2.35-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
While adjusting my localedata patch script to the latest glibc uploads
I discovered a surprising difference in some categories — for example:
(sid-amd64)tglase@tglase:~ $ LC_ALL=C ./tstspc
U+0009
U+000A
U+000B
U+000C
U+000D
U+0020
(sid-amd64)tglase@tglase:~ $ LC_ALL=C.UTF-8 ./tstspc
U+0009
U+000A
U+000B
U+000C
U+000D
U+0020
U+1680
U+2000
U+2001
U+2002
U+2003
U+2004
U+2005
U+2006
U+2008
U+2009
U+200A
U+2028
U+2029
U+205F
U+3000
The test program is thus: gcc -O2 -Wall -Wextra -Wformat -o tstspc tstspc.c
//cut-here--
#include
#include
#include
#include
int
main(void)
{
wint_t wc;
if (!setlocale(LC_ALL, ""))
err(1, "setlocale");
#define DOIT(lim, fmtstr) do { \
while (wc <= lim) { \
if (iswspace(wc)) \
printf(fmtstr, (unsigned int)wc); \
++wc; \
} \
} while (/* CONSTCOND */ 0)
wc = 0;
DOIT(0x, "U+%04X\n");
DOIT(0x10, "U-%08X\n");
return (0);
}
//cut-here--
In my localedata patch script, I take specific care to change the
copy of i18n_ctype before applying it to C.UTF-8 as follows:
space → ..;
cntrl → ..;
blank → ;
They are as mandated by POSIX for the C locale. I believe I said
in my original 2013 proposal for a C.UTF-8 locale that it should
be as close to C as possible while using UTF-8 as encoding.
For these curious, I’m attaching the current WIP of said script.
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500,
'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages locales depends on:
ii debconf [debconf-2.0] 1.5.79
ii libc-bin 2.35-1
ii libc-l10n 2.35-1
locales recommends no packages.
locales suggests no packages.
-- debconf information:
locales/default_environment_locale: None
locales/locales_to_be_generated:
# -*- mode: sh -*-
#-
# Copyright © 2017, 2020, 2022
# mirabilos
#
# Provided that these terms and disclaimer and all copyright notices
# are retained or reproduced in an accompanying document, permission
# is granted to deal in this work without restriction, including un‐
# limited rights to use, publicly perform, distribute, sell, modify,
# merge, give away, or sublicence.
#
# This work is provided “AS IS” and WITHOUT WARRANTY of any kind, to
# the utmost extent permitted by applicable law, neither express nor
# implied; without malicious intent or gross negligence. In no event
# may a licensor, author or contributor be held liable for indirect,
# direct, other damage, loss, or other issues arising in any way out
# of dealing in the work, even if advised of the possibility of such
# damage or existence of a defect, except proven that it results out
# of said person’s immediate fault when using the work as intended.
#-
# Installs UTF-8 charmap shipped by mirabilos-support generated from
# MirBSD but glibc-compatible into the glibc locale souce directory,
# to update wcwidth data (search for “Character width according to”)
# and the i18n_ctype data taken off glibc git master to enable those
# glyphs added in later UCS versions at all, to (find “It covers”) —
# not always the same version the charmap ships, but close enough at
# least — patching the C.UTF-8 and Turkish localedata appropriately,
# handling i18n for stretch glibc and older as well. This also fixes
# Turkish title-case i→İ and C.UTF-8 supporting UCD 9 only, not just
# making ䷀ fullwidth again (bad width tablegens recently sprouted).
case x$KSH_VERSION in
x'@(#)MIRBSD KSH R'[5-9][0-9]*|x'@(#)MIRBSD KSH R'[1-9][0-9][0-9]*)
;;
*)
echo >&2 "E: need mksh"
exit 255
;;
esac
export LC_ALL=C
unset LANGUAGE
set -e
set -o pipefail
set +e
localedef='localedef --no-archive -A /usr/share/locale/locale.alias'
rv=0
do_localedef() {
print -ru2 -- + $localedef "$@"
$localedef "$@" || rv=1
}
die() {
print -ru2 -- "E: $*"
exit 1
}
set -x
(( USER_ID )) && die need root
cd "$(dirname "$0")" || die cannot chdir
[[ -s UTF-8.gz ]] || die cannot find charmap file
[[ -s i18n_ctype.gz ]] || die cannot find ctype file
[[ -d /usr/share/i18n/charmaps/. ]] || die cannot find charmap directory
[[ -d /usr/share/i18n/locales/. ]] ||
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
> Hello Vasudev, > ok, reverting back would explain reportbug using version 2.34-8. > > But was this core taken at a time where all libc packages > should have been at 2.35-1 ? > Then I don't understand that "Module" line, > which shows the build-id from 2.34-8. Ah sorry I did coredumpctl debug post reverting the libc6. But core file attached is taken when actual 2.35 was installed. > > And if I understand you right the stack smashing > is from "autoreconf --version". > But I could not find it executing any "expr" processes in my test VM. Actually just invoking autoconf was crashing and just executing expr itself was also crashing. If needed I can install latest libc and provide any required information. Do let me know Thanks and Regards Vasudev
Bug#1020559: libc6: After upgrading libc6 expr is crashing with "stack smashing detected"
Am 24.09.22 um 04:24 schrieb Vasudev Kamath: Hi Aurelien, Old libc is because I reverted it as some scripts I use and autoconf as well were breaking. I assume I have mentioned in report that a downgrade solved crash. If I missed sorry about that. Sorry for top posting as I’m replying from my pho e Sent from my iPhone On 24-Sep-2022, at 03:21, Aurelien Jarno wrote: Hi, On 2022-09-23 21:28, Bernhard Übelacker wrote: On Fri, 23 Sep 2022 14:45:07 +0530 Vasudev Kamath wrote: Package: libc6 Version: 2.34-8 I upgraded libc6 to latest released 2.35-1 Module ld-linux-x86-64.so.2 with build-id a03c3b14d371da908a3f22007b3f0c73d1f9f634 Module libc.so.6 with build-id ef3afb43092687d7fcc8167fabdee73f4a3287f1 Module libgmp.so.10 with build-id 25c73b398493c695a013a6d9d493a8316aac0fa0 Module expr with build-id b919757cbc30fbb64b14498222499d972fd80acd Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.79 pn glibc-doc ii libc-l10n 2.35-1 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 ii locales2.35-1 Hello Vasudev, I wonder if this libc6 installation is completed. Because the bug report mentions version 2.34-8 from testing, but e.g. locales and libc-l10n is 2.35-1. Also searching for a package containing the debug information for the build-id from the modules listing returns currently the version 2.34-8 from testing. But the build-id for ld-linux-x86-64.so.2 points to 2.35-1. Maybe the libc package installation got interrupted? Good catch. I also noticed that the libraries seems to be located in /usr/lib/x86_64-linux-gnu/, which is typical of a usrmerge system, but reportbug says "merged-usr: no". Vasudev, you should probably check that you do not have too versions of the glibc on your system, one in /lib/x86_64-linux-gnu/ and another one in /usr/lib/x86_64-linux-gnu/ without the /lib -> usr/lib symlink. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net Hello Vasudev, ok, reverting back would explain reportbug using version 2.34-8. But was this core taken at a time where all libc packages should have been at 2.35-1 ? Then I don't understand that "Module" line, which shows the build-id from 2.34-8. And if I understand you right the stack smashing is from "autoreconf --version". But I could not find it executing any "expr" processes in my test VM. Kind regards, Bernhard
Bug#1019855: Fwd: libc6: immediately crashes with SIGILL on 4th gen Intel Core CPUs (seems related to AVX2 instructions), bricking the whole system
Hi Aurelien, On Tue, Sep 20, 2022 at 11:20:26PM +0200, Aurelien Jarno wrote: > Have you been able to progress on that? Do you need some help for a > specific step? For what it’s worth, I’ve upgraded libc6 on my Haswell system (Xeon E3-1245v3) and everything seems to be working fine. Regards, Stephen signature.asc Description: PGP signature
