Infinite loop over ERANGE from getsockopt
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
New
|
Undecided
|
Unassigned |
Bug Description
Host system: Ubuntu 18.04.3 AMD64
Qemu Version: qemu-arm-static --version
qemu-arm version 2.11.1(Debian 1:2.11+
Emulated System:
Root file system taken from RaspberryPi 3 image
ubuntu-
from http://
Then using system-nspawn with with /usr/bin/
When executing commands like
dpkg -i (--force-all) <...>.deb
or
tar tvf ..
or
tar xvf ..
the hosting qemu-arm-static process goes into an infinite loop of getsockopt calls of the form:
getsockopt(12, SOL_SOCKET, SO_PEERSEC, 0x7fff7cac49d8, [4]) = -1 ERANGE (Numerical result out of range)
I assume that this is because of an infinite retry without checking the actual error code of the call.
strace:
openat(AT_FDCWD, "/lib/arm-
read(12, "\177ELF\
lseek(12, 21236, SEEK_SET) = 21236
read(12, "\0\0\0\
lseek(12, 20856, SEEK_SET) = 20856
read(12, "A2\0\0\
fstat(12, {st_mode=
mmap(0x7f419952
E, -1, 0) = 0x7f419952c000
mmap(0x7f419952
7f419952c000
mprotect(
mmap(0x7f419954
= 0x7f4199540000
close(12) = 0
mprotect(
mprotect(
mmap(0x7f419957
= 0x7f419957b000
rt_sigprocmask(
rt_sigprocmask(
rt_sigprocmask(
) = 0
access(
getpid() = 26
socket(AF_UNIX, SOCK_STREAM|
getsockopt(12, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(12, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
getsockopt(12, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
setsockopt(12, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
setsockopt(12, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
connect(12, {sa_family=AF_UNIX, sun_path=
getsockopt(12, SOL_SOCKET, SO_PEERCRED, {pid=0, uid=0, gid=0}, [12]) = 0
getsockopt(12, SOL_SOCKET, SO_PEERSEC, 0x7fff7cac49d8, [4]) = -1 ERANGE (Numerical result out of
range)
And this last entry repeats endlessly.
description: | updated |
Hi; thanks for this bug report. It looks like it's the same as LP:1823790. The underlying cause is that we don't implement the SO_PEERSEC getsockopt option properly. Unfortunately this option appears to be completely undocumented, which makes it pretty hard for us to implement :-(