#32953: torsocks: Unsupported syscall 157 (prctl) ------------------------+-------------------------------------- Reporter: eirizuhaex | Owner: (none) Type: defect | Status: new Priority: Medium | Component: - Select a component Version: | Severity: Normal Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: ------------------------+-------------------------------------- == Overview
I run `. torsocks on` by default and recently ran into this nuissance: {{{ $ ls 1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568) 1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568) 1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568) 1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568) 1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568) 1579062527 WARNING torsocks[29826]: [syscall] Unsupported syscall number 157. Denying the call (in tsocks_syscall() at syscall.c:568) foo/ bar.baz }}} == Version Info {{{ $ lsb_release --all LSB Version: 1.0 Distributor ID: VoidLinux Description: Void Linux Release: rolling Codename: void $ uname --all Linux lang 5.4.8_1 #1 SMP PREEMPT Sun Jan 5 18:00:07 UTC 2020 x86_64 GNU/Linux $ torsocks --version Torsocks 2.3.0 $ ls --version ls (GNU coreutils) 8.31 ... $ xbps-query -p pkgver libcap # see below for explanation libcap-2.30_1 }}} == Sleuthing the Cause Grepping the linux kernel syscall table {{{ $ cd path/to/kernel/git/repo/ $ grep 157 arch/x86/entry/syscalls/syscall_64.tbl 157 common prctl __x64_sys_prctl }}} So it looks like coreutils' ls is (eventually) calling prctl; indeed {{{ $ strace -e prctl ls prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1 prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x28 /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, CAP_BLOCK_SUSPEND) = 1 prctl(PR_CAPBSET_READ, 0x26 /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, CAP_AUDIT_READ) = 1 foo/ bar.baz }}} which correspondings nicely with the six warnings from above. The issue appeared quite recently on my machine; however, both the torsocks and coreutils I am running are not particularly new and have been running on my system for a while. Doing a little spelunking: {{{ $ ldd /usr/bin/ls linux-vdso.so.1 (0x00007ffcfb53d000) /usr/lib/torsocks/libtorsocks.so (0x00007f1e5509e000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007f1e5507f000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f1e54ebc000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f1e54eb7000) /lib/ld-linux-x86-64.so.2 (0x00007f1e550dc000) }}} libcap looks the most suspicious, and indeed, on my system it is the only library that has been recently updated: {{{ $ xilog libcap-2.30 libcap-2.30_1 : 2020-01-07 09:13 JST }}} So we can be reasonably confident that a recent libcap update unearthed this potential regression. == Comments The security implications of `prctl` are beyond my expertise, but given that it manages capabilities, I am guessing this would not be a trivial patch. Is there any hope this could be fixed or mitigated? -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32953> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs