upsc segfaults (SIGSEGV) when querying remote upsd on FreeBSD 14.x with NUT 2.8.5

[Drinker09]

Environment

Affected: NUT 2.8.5_1 on FreeBSD 14.3-RELEASE-p12 (OPNsense 26.1)
Working: NUT 2.8.2_1 on FreeBSD 15.0-RELEASE-p5
UPS Server: Raspberry Pi running NUT 2.8.1 in netserver mode (Raspberry Pi OS)
UPS: CyberPower CP1500PFCLCDa (usbhid-ups driver)

Describe the bug

When running upsc on FreeBSD 14.3 with NUT 2.8.5 to query a remote upsd server, the process terminates with a segmentation fault (SIGSEGV, exit code 11) after successfully connecting and receiving data — but before writing any output. This means no UPS data is returned to stdout regardless of whether output is redirected to a file, pipe, or captured by a calling process such as PHP shell_exec().
The same query against the same remote server works correctly on FreeBSD 15.0 with NUT 2.8.2, suggesting a regression introduced between NUT 2.8.2 and 2.8.5.

To Reproduce

On a FreeBSD 14.3 system with NUT 2.8.5 installed, query a remote NUT server:
upsc upsname@192.168.x.x
Expected result:
battery.charge: 100
battery.runtime: 11425
ups.status: OL
... (full variable list)
Actual result:
Segmentation fault
With output redirected to a file:
upsc upsname@192.168.x.x > /tmp/output.txt
Segmentation fault
The file is empty — no output is written before the crash.
Verified exit code is 11 (SIGSEGV) via PHP exec():
phpexec('/usr/local/bin/upsc upsname@192.168.x.x', $output, $return_code);
// $return_code = 11, $output = []

Additional context

The remote server itself is functioning correctly — other clients on the network can query it without issue. The NUT protocol socket connection works perfectly when implemented directly in PHP using fsockopen() on port 3493, retrieving full UPS data without any crash. This confirms the remote server is healthy and the bug is specific to the upsc binary when querying remote hosts.

This bug was discovered while attempting to use upsc from within the OPNsense NUT plugin's PHP diagnostics controller. The workaround implemented was to bypass upsc entirely and communicate with the remote upsd directly via TCP socket using the NUT protocol.

Workaround

Connect directly to upsd via TCP socket on port 3493 using the NUT protocol instead of calling upsc. Example in PHP:
php$socket = fsockopen('192.168.x.x', 3493, $errno, $errstr, 5);
fwrite($socket, "LIST VAR upsname\n");
// read response...

[jimklimov]

That's very unexpected, thanks for the report. Does that leave a core file, can you post a stack trace from that, or from a new run? e.g.

:; gdb --args upsc -DDDDDD upsname@192.168.x.x
(gdb) run
... program crashes, hopefully with some debug messages before that to help pinpoint the location

(gdb) bt
... stack trace

Also, does it crash in any case, e.g. when printing out help? What details does upsc -Dh show if it succeeds (I specifically wonder if that build is using separated "libnutprivate*" libraries and problems are related to that or not)?

[Drinker09]

Thank you for the quick response! Here is the requested information.

upsc -Dh output (relevant portions):

Network UPS Tools version 2.8.5 release, 64-bit build for amd64, built with FreeBSD clang version 19.1.7; Target: x86_64-unknown-freebsd14.3;
Thread model: posix [D1:libupsclient:upsc] Using NUT libupsclient library version 2.8.5 built with SSL support: OpenSSL
No separated libnutprivate libraries are present. The build uses OpenSSL.

Stack trace via lldb:

Process stopped
  thread #1, name = 'upsc', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x0)
    frame #0: 0x00000008235898da libthr.so.3`___lldb_unnamed_symbol656 + 26
    frame #1: 0x00000008227e1d59 libcrypto.so.12`CRYPTO_THREAD_read_lock + 9
    frame #2: 0x00000008227cfedf libcrypto.so.12`___lldb_unnamed_symbol7844 + 95
    frame #3: 0x00000008227e0963 libcrypto.so.12`___lldb_unnamed_symbol8084 + 35
    frame #4: 0x00000008227cfb72 libcrypto.so.12`OSSL_LIB_CTX_free + 98
    frame #5: 0x00000008254ae026 legacy.so`___lldb_unnamed_symbol222 + 22
    frame #6: 0x00000008227de4cd libcrypto.so.12`___lldb_unnamed_symbol8029 + 61
    frame #7: 0x00000008227aa430 libcrypto.so.12`EVP_CIPHER_free + 80
    frame #8: 0x000000082213feda libssl.so.12`SSL_CTX_free + 570
    frame #9: 0x000000082163b685 libupsclient.so.7`upscli_cleanup + 21
    frame #10: 0x0000000000208ef7 upsc`___lldb_unnamed_symbol215 + 71
    frame #11: 0x0000000824ea0384 libc.so.7`__cxa_finalize + 356
    frame #12: 0x0000000824ea092c libc.so.7`exit + 76
    frame #13: 0x0000000000208c89 upsc`___lldb_unnamed_symbol212 + 1513
    frame #14: 0x0000000824dce334 libc.so.7`__libc_start1 + 292
    frame #15: 0x0000000000208614 upsc`___lldb_unnamed_symbol209 + 36

Analysis:

The crash occurs during program exit cleanup, not during data retrieval. This explains why all UPS data prints successfully but the process crashes before returning to the shell — and why output is empty when redirected, since the shell only captures output after the process exits cleanly.

The call chain shows:

exit() triggers __cxa_finalize cleanup destructors
upscli_cleanup attempts to free the SSL context via SSL_CTX_free
This leads to OSSL_LIB_CTX_free → CRYPTO_THREAD_read_lock
The thread library (libthr.so.3) crashes dereferencing a null pointer at fault address 0x0

This appears to be an OpenSSL cleanup bug in upscli_cleanup() — SSL resources are being freed in an invalid state or order during exit. The crash does not occur on FreeBSD 15.0 with NUT 2.8.2, suggesting a regression introduced between those versions, possibly related to changes in OpenSSL handling in libupsclient.

[jimklimov]

In v2.8.2 the upscli_cleanup was not called from upsc.c at all.

Looking at code, SSL_CTX_free is only called from that method, and only once if ssl != NULL (it is then reset to NULL).

Whad does debug log say - was SSL successfully started by the client? Or did it somehow skip out with it half-baked, or not started at all somehow?

[Drinker09]

Here is the full debug output from upsc -DDDDDD ups@192.168.20.5:

0.000564 [D1:libupsclient] upscli_init_default_connect_timeout: upscli_default_connect_timeout=10.000000 sec assigned from: default_secs
0.001393 [D4:libupsclient] upscli_find_host_cert: no-op when libupsclient was not built WITH_NSS
0.001408 [D3:libupsclient] upscli not initialized, force initialisation without SSL configuration
0.008480 [D1:libupsclient] upscli_init: completed
0.008512 [D3:libupsclient] upscli_sslinit: Trying to STARTTLS
0.009084 [D3:libupsclient] upscli_sslinit: STARTTLS not supported or init error: ERR FEATURE-NOT-CONFIGURED
0.009097 [D3:libupsclient] Can not connect to NUT server 192.168.20.5 in SSL, continue unencrypted
0.009108 [D1] Calling list_vars()
... (all UPS variables retrieved successfully) ...
0.010698 [D1:libupsclient] upscli_disconnect: We logged out, and server said 'OK Goodbye' nicely, as expected
Segmentation fault

Analysis:

The debug output makes the sequence look like:

1. SSL was initialized (upscli_init: completed)

2. STARTTLS was attempted but failed — ERR FEATURE-NOT-CONFIGURED — because the remote NUT server (Raspberry Pi running NUT 2.8.1) is not configured for SSL

3. The connection fell back to unencrypted successfully

4. All UPS variables were retrieved correctly

5. The server disconnected cleanly with OK Goodbye

6. upscli_cleanup then crashed with SIGSEGV during SSL context cleanup

This confirms your suspicion — SSL was in a half-initialized state: initialized enough to require cleanup, but never fully established due to the STARTTLS failure. When upscli_cleanup subsequently calls SSL_CTX_free, it encounters this inconsistent state and crashes.

This regression appears to have been introduced between NUT 2.8.2 and 2.8.5, as you say that upscli_cleanup was not called from upsc.c in 2.8.2. The fix likely needs to ensure that SSL_CTX_free is only called when SSL was fully and successfully initialized, or that the SSL context is properly reset to a safe state when STARTTLS fails and the connection falls back to unencrypted.

[jimklimov]

Thanks! More specifically, this came late in v2.8.5 release cycle as it (and 2.8.6) focus on SSL modernization.

[Drinker09]

Thank you! I really appreciate your time and efforts! It is much appreciated! Have a great one!