Created attachment 3478 [details] Patch to fix this issue. This is a follow on to #3260, opened as a new issue at Darren Tucker's suggestion. (I had emailed him, so will copy a rework of that email here.) I have a i686 Linux VM that I use for building 32-bit. Upgraded to glibc 2.33, and encountered SIGSYS as others reported. The newest 8.5p1 with the fixes from #3260 works fine, if one uses a standard configuration of OpenSSL as likely shipped by the OS distro. But when fixing a "feature" of OpenSSL that causes non-blocking reads to block, one additional syscall is required in addition to those addressed by #3260. I'll upload a trivial 3-liner fix. OpenSSL has a feature that allows user code to specify the source of entropy used, usually /dev/random or /dev/urandom on *nix. Recent OpenSSL checks whether glibc supports the getrandom(2) call, and if so, uses it; but in doing so, it ignores and bypasses the user's specified source of entropy. In particular, when reading random bytes in non-blocking mode, getrandom() will block until the kernel's entropy pool has "initialized." On a VM in a quiet isolated network, that can take up to several minutes in my experience, causing SSH connections to a newly booted machine to hang for the duration. (Other services, e.g. www, smtp, are of course similarly affected.) I "fixed" this locally by fooling OpenSSL's configure script to ignore the getrandom() call entirely, using only the entropy sources specified by user code. Works wonderfully! But, it evidently uses one syscall not used when getrandom() is called, and that is __NR_fstatat64. When OpenSSH is patched to allow that syscall, sshd will once again permit incoming connections.
Does the call need to succeed, or would allowing the call to fail with EACCES be sufficient? ie SC_DENY(__NR_fstatat64), EACCES), similar to the other *stat* calls in that file?
Created attachment 3480 [details] Updated patch, seems to work fine Interesting theory, to label a required syscall as a "deny". Counterintuitive, so I didn't try that before. However, just tested the update, attached as a patch, and it works fine as a deny. Seems safer, though I'd be happier if I knew the odd mechanics there.
Thanks for the report and patch. It's been applied and will be in the next release.
Terrific. Thanks.
closing resolved bugs as of 8.6p1 release