strace shows lscpu cannot find util-linux.mo. This file indeed doesn't exist in that directory. openat(AT_FDCWD, "/usr/share/locale/C.UTF8/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/C.utf8/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/C/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x70} --- I have tried setting en_US as locale and regenerating locale file, source /etc/profile and re-emerging util-linux. None of it worked. Inspect into /usr/share/locale/C.UTF8, this folder doesn't exist at all. /usr/share/locale/en_US/LC_MESSAGES does exist, but there is no util-linux.mo in it. Reproducible: Always Steps to Reproduce: 1. simply run lscpu on a riscv device or qemu environment Actual Results: segment fault
Created attachment 724540 [details] strace lscpu
Created attachment 724543 [details] gdb backtrace
I have tried this on a qemu riscv64 virtual machine as well as real sifive unleash board. Both can reproduce this problem.
Sorry, previously the title was mistook as 2.36.2. The version that I got this bug is 2.37. I have not tested on 2.36.2. apology about that
Segfault confirmed. However, but it has got nothing to do with util-linux.mo, on amd64 setting LC_MESSAGES=C.UTF8 makes strace show exactly the same ENOENTs yet lscpu continues undeterred - as any nls-compliant should well do, since all an unsupported locale should do is force falling back to the defaults. Just to be sure though, I have tried running lscpu on riscv with LC_MESSAGES pointing to one of the locales which util-linux DOES provide - and it still segfaults. Unfortunately your current gdb backtrace is of limited use because of missing information, that said what is already there suggests lscpu might make assumptions about what information is available for displaying which are not necessarily met on rv64. Given there have been similar issues with it in the past on other relatively new arches (e.g. arm64), I am not entirely surprised. Could you try capturing a backtrace having first re-emerged sys-apps/util-linux with FEATURES=nostrip or FEATURES=splitdebug, please?
This looks like a bug: https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu.c#L975 Return value from lscpu_cputype_get_default() can be NULL, but is dereferenced few lines later without check: https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu.c#L994
And it is wrong few lines later again: https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu.c#L1036 https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu.c#L1038
(In reply to Stephan Hartmann from comment #6) > This looks like a bug: > > https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu.c#L975 > > Return value from lscpu_cputype_get_default() can be NULL, but is > dereferenced few lines later without check: > > https://github.com/karelzak/util-linux/blob/master/sys-utils/lscpu.c#L994 exactly the problem here: (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /var/tmp/portage/sys-apps/util-linux-2.37.1/image/usr/bin/lscpu Breakpoint 1, print_summary (cxt=0x2aaaace4b0) at /var/tmp/portage/sys-apps/util-linux-2.37.1/work/util-linux-2.37.1/sys-utils/lscpu.c:969 969 if (ct->addrsz) (gdb) print ct $2 = (struct lscpu_cputype *) 0x0 btw, you may want to apply this patch[1] to solve the gdb dwarf issue [1] https://sourceware.org/pipermail/gdb-patches/2021-June/180228.html
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a8c8e0a371b8b48481ff8d79c0841e20a8ce78d8 commit a8c8e0a371b8b48481ff8d79c0841e20a8ce78d8 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2021-07-30 12:16:59 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2021-07-30 12:20:58 +0000 sys-apps/util-linux-2.37.1: fix lscpu segfault on some arches Observed on rv64 but could in princple happen elsewhere too. Bug: https://bugs.gentoo.org/802606 Signed-off-by: Marek Szuba <marecki@gentoo.org> .../files/util-linux-2.37.1-lscpu_nullptr.patch | 26 ++++++++++++++++++++++ sys-apps/util-linux/util-linux-2.37.1.ebuild | 4 ++++ 2 files changed, 30 insertions(+)
On my BeagleV lscpu runs fine now: # lscpu Architecture: riscv64 Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1
Meh, this should have been accompanied by a revbump because it's a change to runtime behaviour... My bad. That said, this has just been fixed upstream so hopefully there will be a new full version soon. Oh, and belated thanks for having tracked this down sultan!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=da60551412d12ea1b7b0fe27a7603fb7873d63c2 commit da60551412d12ea1b7b0fe27a7603fb7873d63c2 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2021-08-11 12:25:48 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2021-08-11 12:30:42 +0000 sys-apps/util-linux: Revbump to add various upstream fixes * Erase names in agetty by pressing CTRL-C (#804972) * Fixed user mount of davfs2 filesystems (#805218) * Fixed lscpu segfault on riscv plattform with upstream patch (#802606) + Fixed potential buffer overflow in ipcutils (#806070) (CVE-2021-37600) Bug: https://bugs.gentoo.org/806070 Closes: https://bugs.gentoo.org/804972 Closes: https://bugs.gentoo.org/805218 Closes: https://bugs.gentoo.org/802606 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> .../util-linux-2.37.1-agetty_ctrl-c_erase.patch | 50 +++ .../util-linux-2.37.1-ipcutils_calloc_check.patch | 25 ++ .../util-linux-2.37.1-libmount_setgroups_fix.patch | 38 +++ ...l-linux-2.37.1-lscpu_NULL_dereference_fix.patch | 50 +++ sys-apps/util-linux/util-linux-2.37.1-r1.ebuild | 338 +++++++++++++++++++++ 5 files changed, 501 insertions(+)