frankfarmer

We're using libcurl via PHP (I know, I know) which doesn't expose curl_global_init at all.

Here's the stacktrace for the /dev/urandom read -- it's happening in curl_easy_init.

   Catchpoint 1 (call to syscall 'ioctl'), 0x0000003a74ecc4ba in tcgetattr () from /lib64/libc.so.6
   (gdb) backtrace
   #0  0x0000003a74ecc4ba in tcgetattr () from /lib64/libc.so.6
   #1  0x0000003a74ec7a1c in isatty () from /lib64/libc.so.6
   #2  0x0000003a74e60d51 in _IO_file_doallocate_internal () from /lib64/libc.so.6
   #3  0x0000003a74e6d6dc in _IO_doallocbuf_internal () from /lib64/libc.so.6
   #4  0x0000003a74e6ba7c in _IO_file_xsgetn_internal () from /lib64/libc.so.6
   #5  0x0000003a74e61dd2 in fread () from /lib64/libc.so.6
   #6  0x0000003341606414 in ares_init_options () from /usr/lib64/libcares.so.2
   #7  0x0000003d3404f0c9 in ?? () from /usr/lib64/libcurl.so.4
   #8  0x0000003d340242a5 in ?? () from /usr/lib64/libcurl.so.4
   #9  0x0000003d3402f9a6 in curl_easy_init () from /usr/lib64/libcurl.so.4
   #10 0x00002b35e0304fb0 in ?? () from /usr/lib64/php/modules/curl.so
   #11 0x0000000000606da9 in ?? ()
   #12 0x00000000006456b8 in execute_ex ()
   #13 0x00000000005d2bba in zend_execute_scripts ()
   #14 0x00000000005769ee in php_execute_script ()
   #15 0x000000000067e44d in ?? ()
   #16 0x000000000067ede8 in ?? ()
   #17 0x0000003a74e1d994 in __libc_start_main () from /lib64/libc.so.6
   #18 0x0000000000422b09 in _start ()
   (gdb)

Simply initializing a curl handle causes the /dev/urandom read -- so a large number of parallel curl requests easily triggers this issue.

the c-ares init (which reads /dev/urandom) inside curl init happens even when DNS isn't used at all (even when making a request to 127.0.0.1), so it's pretty hard to avoid as long as curl is built with c-ares. The only way to mitigate is to remove c-ares or limit calls to curl init.