[Bug 1906250] Autopkgtest regression report (glibc/2.32-0ubuntu3.1)
Ubuntu SRU Bot
1906250 at bugs.launchpad.net
Mon Dec 21 11:30:33 UTC 2020
All autopkgtests for the newly accepted glibc (2.32-0ubuntu3.1) for groovy have finished running.
The following regressions have been reported in tests triggered by the package:
snapd-glib/1.58-0ubuntu0.20.10.0 (armhf)
libcompress-raw-bzip2-perl/unknown (armhf)
node-ws/7.3.0+~cs24.0.3-1build1 (s390x, armhf, ppc64el, amd64, arm64)
austin/unknown (armhf)
r-bioc-rhdf5lib/1.10.1+dfsg-1 (armhf)
tup/0.7.8-3 (arm64)
r-cran-seurat/unknown (armhf)
python-pomegranate/unknown (armhf)
ruby-mysql2/0.5.2-1ubuntu3 (armhf)
libdevel-cover-perl/1.36-1build1 (armhf)
undbx/unknown (armhf)
libtime-warp-perl/0.54-1build1 (ppc64el)
statsprocessor/unknown (armhf)
pycurl/7.43.0.2-7 (armhf)
libhash-fieldhash-perl/unknown (armhf)
reprotest/0.7.15 (s390x)
r-cran-httpuv/1.5.4+dfsg-1 (armhf)
libosinfo/unknown (armhf)
r-cran-batchtools/unknown (armhf)
chiark-tcl/1.3.4ubuntu3 (armhf)
libdbd-mariadb-perl/1.11-3ubuntu2 (s390x, ppc64el, amd64, arm64)
firefox/84.0+build3-0ubuntu0.20.10.1 (arm64)
hilive/2.0a-3build2 (amd64)
etcd/3.2.26+dfsg-8 (amd64)
libdbd-mariadb-perl/unknown (armhf)
prometheus/unknown (armhf)
libticonv/unknown (armhf)
notary/0.6.1~ds2-6 (armhf)
firebird3.0/unknown (armhf)
burrow/unknown (armhf)
ruby-stackprof/0.2.15-2 (arm64)
gnutls28/3.6.15-4ubuntu2 (i386, amd64, s390x, arm64, ppc64el, armhf)
postgresql-plproxy/2.9-2 (armhf)
librg-blast-parser-perl/0.03-6build2 (armhf)
binutils/2.35.1-1ubuntu1 (armhf)
clutter-1.0/1.26.4+dfsg-1 (arm64)
transtermhp/2.09-5 (armhf)
genext2fs/1.5.0-1 (s390x)
python-cmarkgfm/unknown (armhf)
libpff/20180714-2 (s390x, armhf, ppc64el, amd64, arm64)
debsig-verify/unknown (armhf)
bosh/unknown (armhf)
casync/2+20190213-1 (amd64)
golang-github-spf13-cobra/unknown (armhf)
tpm2-tools/unknown (armhf)
umockdev/0.14.3-1 (armhf)
crrcsim/unknown (armhf)
postgis/3.0.2+dfsg-2ubuntu2 (amd64)
r-cran-proc/unknown (armhf)
mercurial/5.5.1-1 (armhf)
r-cran-dqrng/unknown (armhf)
frobby/unknown (armhf)
libcrypt-cast5-perl/unknown (armhf)
drumkv1/0.9.17-1 (ppc64el)
nsf/unknown (armhf)
python3-lxc/1:3.0.4-1ubuntu6 (s390x)
hyphy/2.5.1+dfsg-3build1 (amd64)
fatrace/0.16-1 (arm64)
bio-rainbow/unknown (armhf)
python-fabio/0.10.2+dfsg-2 (armhf)
hhsuite/3.2.0-3 (amd64)
libperlio-layers-perl/0.012-1 (armhf)
postgresql-common/unknown (armhf)
menhir/20200624-1 (s390x)
notify-osd/0.9.35+20.04.20191129-0ubuntu1 (ppc64el)
r-cran-xfun/unknown (armhf)
gifsicle/1.92-2 (armhf)
libunix-processors-perl/unknown (armhf)
freebayes/unknown (armhf)
alertmanager-irc-relay/0.1.0-3 (arm64)
Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/groovy/update_excuses.html#glibc
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1906250
Title:
Segmentation fault in s390x ld.so while parsing /etc/ld.so.cache using
qemu-s390x on x86_64.
Status in GLibC:
Fix Released
Status in Ubuntu on IBM z Systems:
In Progress
Status in cross-toolchain-base package in Ubuntu:
New
Status in glibc package in Ubuntu:
In Progress
Status in cross-toolchain-base source package in Focal:
Fix Committed
Status in glibc source package in Focal:
Fix Committed
Status in cross-toolchain-base source package in Groovy:
Invalid
Status in glibc source package in Groovy:
Fix Committed
Bug description:
---Problem Description---
On a x86_64 machine with Ubuntu 20.04, running a s390x (or ppc64) binary with qemu leads to a segmentation fault in ld.so while lookup in /etc/ld.so.cache.
Contact Information = via bugzilla
---uname output---
Linux 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
---Steps to Reproduce---
- apt-get install -y --no-install-recommends gcc-s390x-linux-gnu libc6-dev-s390x-cross qemu-user
- apt list --installed "libc6*"
libc6/focal-updates,now 2.31-0ubuntu9.1 amd64 [installed,automatic]
libc6-s390x-cross/focal,focal,now 2.31-0ubuntu7cross1 all [installed,automatic]
...
- echo 'int main(void) { puts("Hello, world!"); }' | s390x-linux-gnu-
gcc -o helloworld-s390x -x c -
- qemu-s390x -strace -L /usr/s390x-linux-gnu ./helloworld-s390x
18392 brk(NULL) = 0x0000004000003000
18392 uname(0x4000803402) = 0
18392 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
18392 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3
18392 fstat(3,0x0000004000802720) = 0
18392 mmap(0x0000004000802648,65784,PROT_READ,MAP_PRIVATE,3,0x82d140) = 0x000000400082e000
18392 close(3) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x0000004300a6e000} ---
Segmentation fault (core dumped)
- qemu-s390x -L /usr/s390x-linux-gnu -g 12345 ./helloword-s390x
- gdb-multiarch ./helloword-s390x
target remote localhost:12345
c
Program received signal SIGSEGV, Segmentation fault.
0x000000400081c572 in ?? ()
Dump of assembler code from 0x400081c500 to 0x400081c600:
...
0x000000400081c564: l %r4,216(%r11)
0x000000400081c568: agr %r10,%r1
0x000000400081c56c: sllg %r10,%r10,3
=> 0x000000400081c572: l %r1,52(%r10,%r6)
0x000000400081c576: lgdr %r2,%f8
0x000000400081c57a: algfr %r3,%r1
0x000000400081c57e: clrjnh %r4,%r1,0x400081c5a0
0x000000400081c584: brasl %r14,0x400081c290
This happens in <glibc>/elf/dl-cache.c:_dl_load_cache_lookup():
ld.so.cache is mmaped with:
void *file = _dl_sysdep_read_whole_file (LD_SO_CACHE, &cachesize, PROT_READ);
And this check is true:
if (file != MAP_FAILED && cachesize > sizeof *cache_new
&& memcmp (file, CACHEMAGIC_VERSION_NEW,
sizeof CACHEMAGIC_VERSION_NEW - 1) == 0)
{
cache_new = file;
cache = file;
}
The segmentation fault happens in SEARCH_CACHE macro which is also defined in elf/dl-cache.c:
if (cache_new != (void *) -1)
{
...
SEARCH_CACHE (cache_new);
}
#define SEARCH_CACHE(cache)
...
left = 0;
right = cache->nlibs - 1;
middle = (left + right) / 2;
key = cache->libs[middle].key;
...
(gdb) p/x *((struct cache_file_new *) $r6)
$5 = {magic = {0x67, 0x6c, 0x69, 0x62, 0x63, 0x2d, 0x6c, 0x64, 0x2e, 0x73, 0x6f, 0x2e, 0x63, 0x61, 0x63, 0x68, 0x65}, version = {0x31, 0x2e,
0x31}, nlibs = 0x5e000000, len_strings = 0x48130000, unused = {0x0, 0x0, 0x0, 0x0, 0x0}, libs = 0x3fffdf00030}
(gdb) ptype cache_new
type = struct cache_file_new {
char magic[17];
char version[3];
uint32_t nlibs;
uint32_t len_strings;
uint32_t unused[5];
struct file_entry_new libs[0];
} *
As /etc/ld.so.cache is generated by x86_64 (little endian) code, we
get a huge number for nlibs on s390x (big endian).
The segfault happens while:
l %r1,52(%r10,%r6)
=> key = cache->libs[middle].key;
(gdb) i r r6
r6 0x3fffdf00000 => cache_new
(gdb) p &(((struct cache_file_new *) $r6)->libs[0])
$17 = (struct file_entry_new *) 0x3fffdf00030
(gdb) p &(((struct cache_file_new *) $r6)->libs[0].key)
$18 = (uint32_t *) 0x3fffdf00034
=> 0x3fffdf00034 - 0x3fffdf00000 = 0x34 = 52
On glibc upstream > glibc-2.31 && < glibc-2.32,
there is the following commit which adds a further check for corruption, avoiding overflow:
"ld.so: Check for new cache format first and enhance corruption check"
https://sourceware.org/git/?p=glibc.git;a=commit;h=e221c512c74ec42fd47b71de2981a475b38110a4
I've recognized that the libc6-2.31-0ubuntu9.1 package contains the patch
debian/patches/any/submitted-ld.so-cache-new-format.diff
which already patches elf/dl-cache.c in _dl_load_cache_lookup().
Therefore the mentioned commit does not apply.
For testing, I've added this patch and just rebuild the libc6-s390x-cross package:
cat glibc-ldsocache-corruption.diff
--- glibc-2.31/elf/dl-cache.c 2020-11-26 15:36:33.963032580 +0100
+++ glibc-2.31/elf/dl-cache.c 2020-11-26 15:39:13.866894100 +0100
@@ -202,13 +202,16 @@
PROT_READ);
/* We can handle three different cache file formats here:
+ - only the new format
- the old libc5/glibc2.0/2.1 format
- the old format with the new format in it
- - only the new format
The following checks if the cache contains any of these formats. */
if (file != MAP_FAILED && cachesize > sizeof *cache_new
- && memcmp (file, CACHEMAGIC_VERSION_NEW,
- sizeof CACHEMAGIC_VERSION_NEW - 1) == 0)
+ && memcmp (file, CACHEMAGIC_VERSION_NEW,
+ sizeof CACHEMAGIC_VERSION_NEW - 1) == 0
+ /* Check for corruption, avoiding overflow. */
+ && ((cachesize - sizeof *cache_new) / sizeof (struct file_entry_new)
+ >= ((struct cache_file_new *) file)->nlibs))
{
cache_new = file;
cache = file;
Now the additional check leads to unmapping ld.so.cache and ignoring the content of ld.so.cache.
The hello-world program is now working fine.
Please add this patch to libc6 package and also rebuild the
libc6-*cross packages.
Just as reference:
"Debian Bug report logs - #731082 ld.so.cache parsing code does not deal with mixed endianess multiarch, causing segfaults"
Date: Sun, 1 Dec 2013 19:30:01 UTC
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731082
To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1906250/+subscriptions
More information about the foundations-bugs
mailing list