The child process handling a customer login to an embedded system crashed on a fatal assert. The following backtrace was recovered from logs:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fe72da6a535 in __GI_abort () at abort.c:79
#2  0x00007fe72dac1648 in __libc_message (action=action@entry=(do_abort | do_backtrace), fmt=fmt@entry=0x7fe72dbcae9c "%s") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007fe72dac1672 in __GI___libc_fatal (message=0x7fffbe8f3f70 "Unexpected error 9 on netlink descriptor 3.\n") at ../sysdeps/posix/libc_fatal.c:191
#4  0x00007fe72db5f264 in __GI___netlink_assert_response (fd=fd@entry=3, result=<optimized out>) at ../sysdeps/unix/sysv/linux/netlink_assert_response.c:102
#5  0x00007fe72db5ea63 in make_request (pid=22108, fd=3) at ../sysdeps/unix/sysv/linux/check_pf.c:171
#6  __check_pf (seen_ipv4=seen_ipv4@entry=0x7fffbe8f5232, seen_ipv6=seen_ipv6@entry=0x7fffbe8f5233, in6ai=in6ai@entry=0x7fffbe8f5240, in6ailen=in6ailen@entry=0x7fffbe8f5248) at ../sysdeps/unix/sysv/linux/check_pf.c:329
#7  0x00007fe72db2c5a7 in __GI_getaddrinfo (name=<optimized out>, service=0x0, hints=0x7fffbe8f5710, pai=0x7fffbe8f5708) at ../sysdeps/posix/getaddrinfo.c:2212
#8  0x00007fe72da24f53 in ?? () from /lib/x86_64-linux-gnu/libaudit.so.1
#9  0x00007fe72da25a32 in audit_log_acct_message () from /lib/x86_64-linux-gnu/libaudit.so.1
#10 0x00007fe72df8f5d4 in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#11 0x00007fe72df8f816 in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#12 0x00007fe72df89b9b in ?? () from /lib/x86_64-linux-gnu/libpam.so.0
#13 0x0000556b3c0bc307 in ?? ()
#14 0x0000556b3c090cf3 in ?? ()
#15 0x00007fe72da6c09b in __libc_start_main (main=0x556b3c08d940, argc=4, argv=0x7fffbe8f84f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbe8f84e8) at ../csu/libc-start.c:308
#16 0x0000556b3c0918ba in ?? ()

The interesting thing is this has happened twice (perhaps more) and the bad fd was 3 both times. From the source I see that descriptor 3 is reserved for a special purpose:
#define REEXEC_DEVCRYPTO_RESERVED_FD    (STDERR_FILENO + 1)

The following are in use: OpenSSL 1.1.1n, libpam 1.3.1-5, pam_tacplus-1.3.8
Linux 4.19.282
libc 2.28-10+deb10u4

The Debian OS is running on a VM. I could provide server and hypervisor details if needed.

Regards,
David Eoll
Microsoft Corp.

I found a place where all FDs from 3 and up are closed with a closefrom() call, and this is done twice. This would seem to provide the opportunity for getaddrinfo() to open a socket on FD 3, which is then closed again before getaddrinfo is done with it. Here are the two closefrom()s:

session.c: 1607    (the closefrom(3) occurs inside the child_close_fds() function):

/*
         * Close the connection descriptors; note that this is the child, and
         * the server will still have the socket open, and it is important
         * that we do not shutdown it.  Note that the descriptors cannot be
         * closed before building the environment, as we call
         * ssh_remote_ipaddr there.
         */
        child_close_fds(ssh);

Then closefrom(3) is called a second time in the same do_child() function at session.c: 1663:

        closefrom(STDERR_FILENO + 1);

I believe this exposes gettaddrinfo() running in a different thread to the condition described in BZ #12926:
12926 - getaddrinfo()/make_request() may spin forever<https://sourceware.org/bugzilla/show_bug.cgi?id=12926>

I also see that both of these closefrom calls have been in place for many years. Is there a reason this FD cleanup is being done twice?

David Eoll
Microsoft Corp.