Solved openssl segmentation faults

[grumbleranch]

Just upgraded to 386.2 on my RT-AC68U. I was working on a custom ddns-start script and curl reported an issue with the HTTPS connection for the API call. I then ran openssl (version 1.1.1k) s_client to check the certificate on the server I was accessing and encountered a segmentation fault.

Thinking the version of openssl might be corrupted, I downgraded the router firmware to 386.1_2 and encountered the same segmentation fault, this time running openssl version 1.1.1i.

The command I was using to generate the segmentation fault in both cases was:

openssl s_client -connect api.godaddy.com:443

This same command runs with no problem on a Red Hat server, but that is of course an older version of openssl.

Does anyone else encounter this error with openssl? I searched the forum and could not find anything related to openssl segmentation faults.

 

[dave14305]

Be sure you are using the built-in openssl and not an Entware version. Use the full path and test again.

/usr/sbin/openssl s_client -connect api.godaddy.com:443

 

[grumbleranch]

That's the only version installed. This is a clean installation of Merlin without any add-ons.

# which openssl
/usr/sbin/openssl
# /usr/sbin/openssl s_client -connect www.google.com:443
Segmentation fault
# /usr/sbin/openssl version
OpenSSL 1.1.1k  25 Mar 2021

Note that I did reinstall 386.2 once I verified that the same segmentation fault occurred with 386.1_2.

 

[dave14305]

What's the output of ldd /usr/sbin/openssl

I have an AC86U, so my results won't be the same as yours.

# ldd /usr/sbin/openssl
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0xf726e000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0xf7035000)
        libdl.so.2 => /lib/libdl.so.2 (0xf7022000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf6ff9000)
        libc.so.6 => /lib/libc.so.6 (0xf6ebb000)
        /lib/ld-linux.so.3 (0xf72ea000)

 

[grumbleranch]

#ldd /usr/sbin/openssl
        libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x401a7000)
        libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x4020c000)
        libdl.so.0 => /lib/libdl.so.0 (0x403f0000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x403fb000)
        libc.so.0 => /lib/libc.so.0 (0x40415000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400d1000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x400c3000)

None of those library files are missing.

 

[john9527]

I just tried on my LTS fork AC68U and didn't encounter the seg fault. In case it helps, here's my 'ldd' output.

admin@RT-AC68P-EC58:/tmp/home/root# /usr/sbin/openssl version
OpenSSL 1.1.1k  25 Mar 2021
admin@RT-AC68P-EC58:/tmp/home/root#  ldd /usr/sbin/openssl
    libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x40267000)
    libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x402cc000)
    libdl.so.0 => /lib/libdl.so.0 (0x40122000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x40057000)
    libc.so.0 => /lib/libc.so.0 (0x4012d000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401d7000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40022000)

 

[grumbleranch]

Backing off to LTS is a little too radical for me at this point. I did install 384.19 and observed that openssl s_client does not generate a segment fault. So something happened with openssl after 384.19. Only problem for me now is that I can't login via the web interface so I probably need to reset the router and clean install 384.19.

 

[RMerlin]

Works fine on my RT-AC66U_B1.

admin@rtac66b1:/tmp/home/root# openssl s_client -connect api.godaddy.com:443
CONNECTED(00000004)
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 C = US, ST = Arizona, L = Scottsdale, O = GoDaddy INC., CN = *.godaddy.com
verify return:1
<snip>

 

[grumbleranch]

I'm running on a RT-AC68U_A2. Does this seem like it might be a hardware problem? Or just a problem of Merlin not working entirely with an older model?

 

[RMerlin]

I'm running on a RT-AC68U_A2. Does this seem like it might be a hardware problem? Or just a problem of Merlin not working entirely with an older model?

Has nothing to do with the revision (they all have the same CPU), this is more likely to be a configuration issue. Hardware issue is possible, but would probably display other stability issues than just with openssl.

Try with an IP address to see if the issue may be related to the resolver (older uclibc have issues for instance with DNS entries that contain too many results).

 

[grumbleranch]

So I ended up doing a factory reset on the router with 384.19 installed. I got everything configured properly for the router and then decided to try upgrading again to 386.2_2. Now both openssl and curl are working properly. I know that there was nothing related to openssl in 386.2_2 vs. 386.2, so I can't explain why I was experiencing segment faults previously. I'm just happy that it's working now with the latest Merlin.