Package: apt Version: 1.6~alpha3 Severity: important Hi, I noticed that with apt 1.6, running apt-get update hangs in a mips64el chroot running on an amd64 host using qemu-user-static. I can also reproduce this with an arm64 target so I suspect this affects all 64-bit architectures running on amd64. It outputs this before hanging (on mips64el): > # apt-get update > 0% [Working]qemu: Unsupported syscall: 5312 > 0% [Working] Syscall 5312 is "seccomp". If I run qemu-user with the -strace option, I see that the http method calls the seccomp syscall which fails with ENOSYS (since it's not supported in qemu). Then, libseccomp calls the old prctl(PR_SET_SECCOMP) syscall which succeeds. I think in this case a valid seccomp filter is installed, but for the wrong architecture. This results in the calling thread being immediately killed when a syscall is later executed. The apt changelog mentions checking for EFAULT in case apt is started inside QEMU. I think this only works by chance on 32-bit targets because they would pass a truncated pointer to the real prctl which the kernel would usually reject as an invalid address. I think the hanging is caused by the http method having two threads. When an invalid syscall is executed under seccomp, only the calling thread is killed. Since the http method is running two threads, the other is left running and hangs. In turn this causes the parent apt process to wait for the http method to exit which will never happen. Thanks, James
Attachment:
signature.asc
Description: OpenPGP digital signature