dietPi-Dashboard TLS handshake with client failed

Creating a bug report/issue

x I have searched the existing open and closed issues

Required Information

  • DietPi version 9.18.1
  • Distro version trixie
  • Kernel version Debian 6.12.48-1 (2025-09-20) x86_64 GNU/Linux
  • Architecture amd64
  • SBC model Native PC (x86_64)
  • Power supply used HP PSU
  • SD card used N/A

Additional Information (if applicable)

  • Software title dietPi-Dashboard
  • installed freshly

Steps to reproduce

  1. …Fresh install of dietpi on a headless HP t630 thin client
  2. …On installing dietpi-Dashboard and starting back and frontends.
  3. In a browser on another computer navigate to 192.168.1.115:5252
  4. No response in browser and log shows
    ”Error serving HTTP connection: TLS handshake with client failed”

Expected behaviour

No response from dietpi-dashboard.
I have tried with Brave and Firefox browsers.
This PC is headless so I have not been able to try with localhost.
Other people do not seem to have this issue so maybe I am doing something stupid.
I have tried prefixing the request with both http:// and https://

Actual behaviour

Extra details

I have tried installing an SSL certificate with certbot, but it makes no difference.

Log shows

Oct 22 18:19:47 DietPi: Started dietpi-dashboard-frontend.service - Dashboard Web Server (DietPi).
Oct 22 18:19:48 DietPi frontend[1905]: 2025-10-22T17:19:48.056Z INFO  [frontend] Starting DietPi-Dashboard frontend v0.7.0...
Oct 22 18:19:48 DietPi frontend[1905]: 2025-10-22T17:19:48.056Z INFO  [frontend::backend] Starting backend server on port 5253
Oct 22 18:19:48 DietPi frontend[1905]: 2025-10-22T17:19:48.056Z INFO  [frontend::http] Starting web server on port 5252
Oct 22 18:20:10 DietPi frontend[1905]: 2025-10-22T17:20:10.513Z ERROR [frontend::http] Error serving HTTP connection: TLS handshake with client failed


these are 2 different thinks. the dashboard has own self signed certificate that is not managed by certbot.

it should be https on a default installation like https://dietpi.lan:5252/

I guess this message is expected as the certificate is self-signed and not accepted by the browser. First you would need to accept the not trusted certificate.

Just tested on a RPI5 without issue. And yes, I have same TLS handshake message in my logs.

@ravenclaw900 maybe you can have a look regarding this message

@delboy711 did you already tried to clear cache of your browser?

Are you absolutely certain you’re getting no response in your browser? Are there any error messages at all? I agree, I also get the same TLS handshake message on a first connection when the certificate is not trusted yet, that is presumably because the browser cuts off the handshake if it doesn’t trust the certificate.

How old is your browser? Does it support TLS 1.3?

Thanks for the reply @ravenclaw900 My browsers are fully up to date. The response is


Unable to connect

Firefox can’t establish a connection to the server at 192.168.1.12:5252.

Both Firefox and Brave browses behave the same,

However the good news is I have it working in http:// mode by disabling TLS in the file config-frontend.toml

I still have no idea why it will not work in https mode.

BTW: Good job. It looks pretty nice :slight_smile:

I’m glad things are working in HTTP mode, but that makes this issue even more confusing to me. The cannot establish a connection error implies that it’s unable to connect to the TCP port entirely, which should be independent of any TLS negotiation.

With HTTPS mode running, could you run ss -tulp | grep ‘525’ on the server? Similarly, could you test curl -v https://localhost:5252 on the server and curl -v https://192.168.1.12:5252 on your other machine? Please post the output of all these commands.

Does your network support IPv6? The dashboard only explicitly listens on IPv6, but Debian should map that to all interfaces on all IP versions anyways. Just in case, please also give the output of `sudo sysctl net.ipv6.bindv6only`.

Thanks for the support @ravenclaw900 . Here are the results

# ss -tulp | grep ‘525’
#

no response

# curl -v https://localhost:5252
* Host localhost:5252 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:5252...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, decode error (562):
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
#

then I did

# systemctl status dietpi-dashboard-frontend
× dietpi-dashboard-frontend.service - Dashboard Web Server (DietPi)
     Loaded: loaded (/etc/systemd/system/dietpi-dashboard-frontend.service; enabled; preset: enabled)
     Active: failed (Result: signal) since Thu 2025-10-23 16:35:35 BST; 1min 32s ago
   Duration: 53.043s
 Invocation: 036825d57367492bb86657e883246c1e
    Process: 7943 ExecStart=/opt/dietpi-dashboard/frontend (code=killed, signal=SEGV)
   Main PID: 7943 (code=killed, signal=SEGV)
   Mem peak: 1.8M
        CPU: 75ms

Oct 23 16:34:42 MF-Treecare systemd[1]: Started dietpi-dashboard-frontend.service - Dashboard Web Server (DietPi).
Oct 23 16:34:42 MF-Treecare frontend[7943]: 2025-10-23T15:34:42.704Z INFO  [frontend] Starting DietPi-Dashboard frontend v0.7.0...
Oct 23 16:34:42 MF-Treecare frontend[7943]: 2025-10-23T15:34:42.704Z INFO  [frontend::backend] Starting backend server on port 5253
Oct 23 16:34:42 MF-Treecare frontend[7943]: 2025-10-23T15:34:42.704Z INFO  [frontend::http] Starting web server on port 5252
Oct 23 16:34:43 MF-Treecare frontend[7943]: 2025-10-23T15:34:43.594Z INFO  [frontend::backend] New backend connection from 127.0.0.1
Oct 23 16:35:35 MF-Treecare systemd[1]: dietpi-dashboard-frontend.service: Main process exited, code=killed, status=11/SEGV
Oct 23 16:35:35 MF-Treecare systemd[1]: dietpi-dashboard-frontend.service: Failed with result 'signal'.
root@MF-Treecare:/opt/dietpi-dashboard# systemctl restart dietpi-dashboard-frontend

So the frontend segfaulted when it got an https request

So I restarted the service and then on another machine

$ curl -v https://192.168.1.115:5252
*   Trying 192.168.1.115:5252...
* connect to 192.168.1.115 port 5252 from 192.168.1.33 port 35520 failed: Connection refused
* Failed to connect to 192.168.1.115 port 5252 after 0 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to 192.168.1.115 port 5252 after 0 ms: Could not connect to server
$

and on the DietPi machine

# systemctl status dietpi-dashboard-frontend
× dietpi-dashboard-frontend.service - Dashboard Web Server (DietPi)
     Loaded: loaded (/etc/systemd/system/dietpi-dashboard-frontend.service; enabled; preset: enabled)
     Active: failed (Result: signal) since Thu 2025-10-23 16:37:47 BST; 36s ago
   Duration: 18.849s
 Invocation: e19615d331f845939fc5b5ed6b70cc32
    Process: 7965 ExecStart=/opt/dietpi-dashboard/frontend (code=killed, signal=SEGV)
   Main PID: 7965 (code=killed, signal=SEGV)
   Mem peak: 2M
        CPU: 75ms

Oct 23 16:37:28 MF-Treecare systemd[1]: Started dietpi-dashboard-frontend.service - Dashboard Web Server (DietPi).
Oct 23 16:37:29 MF-Treecare frontend[7965]: 2025-10-23T15:37:29.076Z INFO  [frontend] Starting DietPi-Dashboard frontend v0.7.0...
Oct 23 16:37:29 MF-Treecare frontend[7965]: 2025-10-23T15:37:29.076Z INFO  [frontend::backend] Starting backend server on port 5253
Oct 23 16:37:29 MF-Treecare frontend[7965]: 2025-10-23T15:37:29.076Z INFO  [frontend::http] Starting web server on port 5252
Oct 23 16:37:42 MF-Treecare frontend[7965]: 2025-10-23T15:37:42.657Z INFO  [frontend::backend] New backend connection from 127.0.0.1
Oct 23 16:37:47 MF-Treecare systemd[1]: dietpi-dashboard-frontend.service: Main process exited, code=killed, status=11/SEGV
Oct 23 16:37:47 MF-Treecare systemd[1]: dietpi-dashboard-frontend.service: Failed with result 'signal'.

segfault again. Then after restarting the service

# sysctl net.ipv6.bindv6only
net.ipv6.bindv6only = 0
# sysctl net.ipv6.bindv6only=1
net.ipv6.bindv6only = 1

Then restart the server and

# curl -v https://localhost:5252
* Host localhost:5252 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:5252...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, decode error (562):
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
root@MF-Treecare:/opt/dietpi-dashboard# systemctl status dietpi-dashboard-frontend
× dietpi-dashboard-frontend.service - Dashboard Web Server (DietPi)
     Loaded: loaded (/etc/systemd/system/dietpi-dashboard-frontend.service; enabled; preset: enabled)
     Active: failed (Result: signal) since Thu 2025-10-23 16:55:26 BST; 9s ago
   Duration: 1min 4.448s
 Invocation: 21abe1f560f74f89997839e509562dba
    Process: 8000 ExecStart=/opt/dietpi-dashboard/frontend (code=killed, signal=SEGV)
   Main PID: 8000 (code=killed, signal=SEGV)
   Mem peak: 2M
        CPU: 72ms

Oct 23 16:54:22 MF-Treecare systemd[1]: Started dietpi-dashboard-frontend.service - Dashboard Web Server (DietPi).
Oct 23 16:54:22 MF-Treecare frontend[8000]: 2025-10-23T15:54:22.119Z INFO  [frontend] Starting DietPi-Dashboard frontend v0.7.0...
Oct 23 16:54:22 MF-Treecare frontend[8000]: 2025-10-23T15:54:22.119Z INFO  [frontend::backend] Starting backend server on port 5253
Oct 23 16:54:22 MF-Treecare frontend[8000]: 2025-10-23T15:54:22.120Z INFO  [frontend::http] Starting web server on port 5252
Oct 23 16:55:26 MF-Treecare systemd[1]: dietpi-dashboard-frontend.service: Main process exited, code=killed, status=11/SEGV
Oct 23 16:55:26 MF-Treecare systemd[1]: dietpi-dashboard-frontend.service: Failed with result 'signal'

So restricting the port to IP6 made no difference. It still segfaults.

Hope that is some use to you.

Could this be due to this being an x86-64 machine. I see the binaries are downloaded from the nightly repo. Could it be a problem with the compiling?

Or could there be a missing dependency? The binaries are not installed with apt so there is no checking for dependencies.

Hmm missing dependencies (shared libraries) would cause a failure with meaningful error mesage right at the start, not when receiving a HTTPS request. There should be none aside of essential packages which are all preinstalled.

But maybe there is some incompatibility between expected and present versions/APIs of shared libraries. I did test the rework including HTTPS access up and down (also on x86_64), but probably not with the latest (build) dependency update. Will retry.

Can you enable debug logs and/or start and test the frontend service with strace?

Works well here :thinking:

root@VM-Trixie:~# curl -k https://127.0.0.1:5252/login
<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>DietPi Dashboard</title><link rel="icon" href="/favicon.svg" type="image/svg+xml"><link rel="stylesheet" href="/static/main.css"></head><body nm-data="navOpen: true, msgsOpen: false, newMsg: false," nm-bind="className: () =&gt; `${navOpen ? '' : 'nav-closed'} ${msgsOpen ? 'msgs-open' : ''}`"><h1>DietPi Dashboard</h1><header><button aria-controls="nav" nm-bind="onclick: () =&gt; navOpen = !navOpen, ariaExpanded: () =&gt; navOpen"><svg width="48" height="48"><use href="/static/icons.svg#fa6-solid-bars"></use></svg></button><label>Backend: <select onchange="document.cookie = `backend=${this.value}; MaxAge=999999999`; window.location.reload()"><option value="127.0.0.1" selected>127.0.0.1 (127.0.0.1)</option></select></label><button class="msg-btn" aria-controls="msgs" nm-bind="onclick: () =&gt; msgsOpen = !msgsOpen, ariaExpanded: () =&gt; msgsOpen"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-envelope"></use></svg><span class="notifier" nm-bind="hidden: () =&gt; !newMsg"><svg width="12" height="12"><use href="/static/icons.svg#fa6-solid-circle"></use></svg></span></button><span nm-data="isDark: localStorage.getItem('darkMode') === 'true'"><meta name="color-scheme" nm-bind="content: () =&gt; isDark ? 'dark' : 'light'"></meta><button nm-bind="
                    onclick: () =&gt; {
                        isDark = !isDark;
                        localStorage.setItem('darkMode', isDark);
                    }
                "><span nm-bind="hidden: () =&gt; isDark"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-sun"></use></svg></span><span nm-bind="hidden: () =&gt; !isDark"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-moon"></use></svg></span></button></span></header><div id="msgs"><ul><li nm-bind="textContent: async () =&gt; {
                    const msg = await getUpdateMessage('0.7.0');
                    newMsg = !!msg;
                    return msg;
                }"></li></ul></div><nav id="nav"><a href="/system"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-gauge"></use></svg>System</a><a href="/process"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-microchip"></use></svg>Processes</a><a href="/software"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-database"></use></svg>Software</a><a href="/service"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-list"></use></svg>Services</a><a href="/management"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-user"></use></svg>Management</a><a href="/terminal"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-terminal"></use></svg>Terminal</a><a href="/browser"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-folder"></use></svg>File Browser</a><a href="/config"><svg width="24" height="24"><use href="/static/icons.svg#fa6-solid-gear"></use></svg>Config</a></nav><main nm-data><p nm-bind="textContent: () =&gt; nmError"></p><section><h2>Login</h2><form method="POST"><input name="pass" type="password" placeholder="Password"></input><br><br><input type="submit"></input></form></section></main><footer>DietPi Dashboard v0.7.0 by ravenclaw900<a href="https://github.com/ravenclaw900/DietPi-Dashboard" target="_blank"><svg width="32" height="32"><use href="/static/icons.svg#cib-github"></use></svg></a></footer><script src="/static/main.js"></script></body></html>

And dependencies are libgcc-s1 and libc6 only:

root@VM-Trixie:~# ldd /opt/dietpi-dashboard/frontend
        linux-vdso.so.1 (0x00007f6cee679000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6cee644000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6cee63f000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6cee63a000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6cee110000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6cee635000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6cedf1a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6cee67b000)

with libc6 required for basically everything, and libgcc-s1 a dependency of apt itself.

In your first log, while there was this expected first TS handshake error until the certificate is accepted in browser, there was no segmentation fault. At which point did this appear? Did you re-enable HTTPS in the frontend config again for the test?

Side note: It is totally expected to apply a proper public CA certificate like from Certbot/Let’s Encrypt if available. We enable HTTPS OOTB with a self-signed one, internally made valid (SAN) for the local hostname and LAN IP, but browser by default do not accept certs not from a known CA. However, also a Let’s Encrypt cert is not accepted when accessing via LAN IP or local hostname, but only for the public hostname, while I would not recommend to make an admin dashboard like this accessible from the Internet. But one can create a local hostname entry pointing to LAN IP to make the public cert work.

I agree with Micha, the only shared library dependency that the dashboard has is glibc, and it would fail immediately if the correct version wasn’t present.

I don’t want to jump to conclusions or make generalizations, but there should be nothing in my code that can cause a segfault (this is not me being overconfident, just a general consequence of writing in Rust). The most likely explanation to me is that there is either a bug in our cryptography library (which would be bad) or your copy of the dashboard is corrupted (which is easy to fix). I doubt debug logs will give us too much info in this scenario. Please attempt to reinstall it and see if that fixes the issue. Otherwise, if you’re willing to do more debugging,

sudo apt install strace
strace -o trace.log ./frontend

and then try and connect and post the log. If this doesn’t segfault, I wonder if the issue could be something with the systemd hardening?

Additionally, I’ve updated the binary to include some debug information (makes it nominally larger, but much easier to debug when scenarios like these happen) Because of that, you could also attempt to use GDB to inspect the core dump after reinstalling the dashboard, which might be more insightful.

sudo apt install gdb
ulimit -c unlimited # Enable core dumps if they're disabled
gdb -batch -ex "bt" ./frontend core

I thought about the same, though it works fine here. And I mean I know those rules, which apply R/O access to the whole system (with /opt/dietpi-dashboard explicitly excluded) and prevent any access to certain paths by basically overmounting them with empty ones: /tmp, /home, /dev (prepared with default nodes, of course). None of these should have an effect on frontend functionality.

But one thing: It has no access to the private TLS key at /etc/letsencrypt/live/domain.org/privkey.pem, since it runs as unprivileged user. I would expect the error message to be a different one if this was applied to the config, but generally it is recommended to create a certbot deploy hook for such cases, which copies the cert and key to /opt/dietpi-dashboard and adjust owner, instead of granting unprivileged software access to the key from certbot directly.

strace.log

execve("./frontend", ["./frontend"], 0x7ffd9b16ba80 /* 15 vars */) = 0
brk(NULL)                               = 0x55c87e5d6000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbdbddcd000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9719, ...}) = 0
mmap(NULL, 9719, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fbdbdd83000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=182856, ...}) = 0
mmap(NULL, 181160, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbdbdd53000
mmap(0x7fbdbdd57000, 143360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7fbdbdd57000
mmap(0x7fbdbdd7a000, 16384, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27000) = 0x7fbdbdd7a000
mmap(0x7fbdbdd7e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2b000) = 0x7fbdbdd7e000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14552, ...}) = 0
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbdbdd4b000
mmap(0x7fbdbdd4c000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fbdbdd4c000
mmap(0x7fbdbdd4d000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fbdbdd4d000
mmap(0x7fbdbdd4e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fbdbdd4e000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14408, ...}) = 0
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbdbdd43000
mmap(0x7fbdbdd44000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fbdbdd44000
mmap(0x7fbdbdd45000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fbdbdd45000
mmap(0x7fbdbdd46000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fbdbdd46000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=977112, ...}) = 0
mmap(NULL, 978968, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbdbdc53000
mmap(0x7fbdbdc64000, 512000, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0x7fbdbdc64000
mmap(0x7fbdbdce1000, 393216, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8e000) = 0x7fbdbdce1000
mmap(0x7fbdbdd41000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xed000) = 0x7fbdbdd41000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14408, ...}) = 0
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbdbdc4b000
mmap(0x7fbdbdc4c000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fbdbdc4c000
mmap(0x7fbdbdc4d000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fbdbdc4d000
mmap(0x7fbdbdc4e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fbdbdc4e000
close(3)                                = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\236\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 840, 64) = 840
fstat(3, {st_mode=S_IFREG|0755, st_size=2003408, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbdbddcb000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 840, 64) = 840
mmap(NULL, 2055800, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbdbda53000
mmap(0x7fbdbda7b000, 1462272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7fbdbda7b000
mmap(0x7fbdbdbe0000, 352256, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18d000) = 0x7fbdbdbe0000
mmap(0x7fbdbdc36000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e2000) = 0x7fbdbdc36000
mmap(0x7fbdbdc3c000, 52856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fbdbdc3c000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbdbdd8a000
arch_prctl(ARCH_SET_FS, 0x7fbdbdd8a880) = 0
set_tid_address(0x7fbdbdd8ab50)         = 8447
set_robust_list(0x7fbdbdd8ab60, 24)     = 0
rseq(0x7fbdbdd8a680, 0x20, 0, 0x53053053) = 0
mprotect(0x7fbdbdc36000, 16384, PROT_READ) = 0
mprotect(0x7fbdbdc4e000, 4096, PROT_READ) = 0
mprotect(0x7fbdbdd41000, 4096, PROT_READ) = 0
mprotect(0x7fbdbdd46000, 4096, PROT_READ) = 0
mprotect(0x7fbdbdd4e000, 4096, PROT_READ) = 0
mprotect(0x7fbdbdd7e000, 4096, PROT_READ) = 0
mprotect(0x55c8557ea000, 65536, PROT_READ) = 0
mprotect(0x7fbdbddc7000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7fbdbdd83000, 9719)            = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 0 (Timeout)
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fbdbda92df0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=
0}, 8) = 0
getrandom("\xfa\x46\xb9\x78\xa9\x08\xc9\x6a", 8, GRND_NONBLOCK) = 8
brk(NULL)                               = 0x55c87e5d6000
brk(0x55c87e5f7000)                     = 0x55c87e5f7000
openat(AT_FDCWD, "/proc/self/maps", O_RDONLY|O_CLOEXEC) = 3
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "55c855400000-55c8555eb000 r-xp 0"..., 1024) = 1024
read(3, "0 08:02 4214                    "..., 1024) = 1024
read(3, "r/lib/x86_64-linux-gnu/libm.so.6"..., 1024) = 1024
read(3, "64-linux-gnu/librt.so.1\n7fbdbdd4"..., 1024) = 1024
read(3, "o.2\n7fbdbdd94000-7fbdbddbc000 r-"..., 1024) = 663
close(3)                                = 0
sched_getaffinity(8447, 32, [0 1 2 3])  = 8
rt_sigaction(SIGSEGV, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
sigaltstack(NULL, {ss_sp=NULL, ss_flags=SS_DISABLE, ss_size=0}) = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fbdbdd87000
mprotect(0x7fbdbdd87000, 4096, PROT_NONE) = 0
sigaltstack({ss_sp=0x7fbdbdd88000, ss_flags=0, ss_size=8192}, NULL) = 0
rt_sigaction(SIGSEGV, {sa_handler=0x55c8555254f0, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_SIGINFO, sa_restorer=0x7fbdbda92df0}, NULL, 8) = 0
rt_sigaction(SIGBUS, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGBUS, {sa_handler=0x55c8555254f0, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_SIGINFO, sa_restorer=0x7fbdbda92df0}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_DROPPABLE|MAP_ANONYMOUS, -1, 0) = 0x7fbdbdd86000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fbdbdd85000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
getrandom("\xb5\x26\x23\x7d\xa1\xf9\xa5\x57\x44\x6e\x60\x20\x7f\xc9\x97\x9f\xd1\x98\xd1\xf6\x88\x04\x71\xc2\x26\x1c\x7c\x09\x98\x8f\x43\x30", 32, 0) = 32
epoll_create1(EPOLL_CLOEXEC)            = 3
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 4
epoll_ctl(3, EPOLL_CTL_ADD, 4, {events=EPOLLIN|EPOLLRDHUP|EPOLLET, data=0}) = 0
fcntl(3, F_DUPFD_CLOEXEC, 3)            = 5
socketpair(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0, [6, 7]) = 0
fcntl(6, F_DUPFD_CLOEXEC, 3)            = 8
epoll_ctl(5, EPOLL_CTL_ADD, 8, {events=EPOLLIN|EPOLLRDHUP|EPOLLET, data=0x1}) = 0
readlink("/proc/self/exe", "/opt/dietpi-dashboard/frontend", 256) = 30
openat(AT_FDCWD, "/opt/dietpi-dashboard/config-frontend.toml", O_RDONLY|O_CLOEXEC) = 9
statx(9, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0640, stx_size=964, ...}) = 0
read(9, "# TCP port and subnet for webser"..., 964) = 964
read(9, "", 32)                         = 0
close(9)                                = 0
ioctl(1, TCGETS, {c_iflag=ICRNL|IUTF8, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|
ECHOKE, ...}) = 0
write(1, "2025-10-23T20:09:53.371Z \33[36mIN"..., 96) = 96
write(1, "2025-10-23T20:09:53.371Z \33[36mIN"..., 97) = 97
socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 9
setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(9, {sa_family=AF_INET6, sin6_port=htons(5253), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_scope_id=0}, 28) = 0
listen(9, 1024)                         = 0
epoll_ctl(5, EPOLL_CTL_ADD, 9, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data=0x55c87e5e3600}) = 0
write(1, "2025-10-23T20:09:53.372Z \33[36mIN"..., 90) = 90
socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 10
setsockopt(10, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(10, {sa_family=AF_INET6, sin6_port=htons(5252), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_scope_id=0}, 28) = 0
listen(10, 1024)                        = 0
epoll_ctl(5, EPOLL_CTL_ADD, 10, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data=0x55c87e5e3800}) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7fbdbdae34b0, sa_mask=[], sa_flags=SA_RESTORER|SA_ONSTACK|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fbdbda92df0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
mmap(NULL, 2101248, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fbdbd852000
mprotect(0x7fbdbd853000, 2097152, PROT_READ|PROT_WRITE) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7fbdbda5299
0, parent_tid=0x7fbdbda52990, exit_signal=0, stack=0x7fbdbd852000, stack_size=0x1ffe40, tls=0x7fbdbda526c0} => {parent_tid=[8448]}, 88) = 8448
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
epoll_wait(3, [{events=EPOLLIN, data=0}], 1024, -1) = 1
futex(0x55c87e5e1748, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55c87e5e1680, FUTEX_WAKE_PRIVATE, 1) = 1
getrandom("", 0, 0)                     = 0
getrandom("\x10\x2a\xce\xed\xea\x1b\xc7\xe3\x8b\x67\xcb\x49\xd1\xec\x89\xef\xed\x50\x0d\xf9\xe4\x1d\x05\xa2\x9a\x66\x0e\x63\xcc\xcc\x5c\x00", 32, 0) = 32
epoll_wait(3, 0x55c87e5d6d20, 1024, -1) = -1 EINTR (Interrupted system call)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

I have uninstalled and reinstalled several times over the last day, but I have done so again to pick up your new version (zipped at 17:59 today)

# gdb -batch -ex "bt" ./frontend core
/opt/dietpi-dashboard/core: No such file or directory.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /opt/dietpi-dashboard/frontend.
Use `info auto-load python-scripts [REGEXP]' to list them.
No stack.

Ah, sorry, I don’t think I was clear enough. I need you to run the program until you get a segfault, so try and connect to it while it’s running. Run it once doing just ./frontend, then that should create the missing core file. It should result in a Segmentation fault (core dumped). Then run the gdb command. So:

./frontend # Get it to segfault
ls # make sure there's a core file (might alse be named core.pid)
gdb -batch -ex "bt" ./frontend core # rename the file if it's different

Not sure if this is new behavior or just clarification of what was happening before.

With the latest binary I start the frontend with ./frontend

$ ./frontend
2025-10-23T21:05:30.412Z INFO  [frontend] Starting DietPi-Dashboard frontend v0.7.0...
2025-10-23T21:05:30.412Z INFO  [frontend::backend] Starting backend server on port 5253
2025-10-23T21:05:30.412Z INFO  [frontend::http] Starting web server on port 5252

On another terminal window I make a query

$ curl -v https://localhost:5252
* Host localhost:5252 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:5252...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS alert, decode error (562):
* TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
* closing connection #0
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading

First terminal window then shows

Segmentation fault
dietpi@MF-Treecare:/opt/dietpi-dashboard$ ls
backend  cert.pem  config-backend.toml  config-frontend.toml  frontend  privkey.pem
dietpi@MF-Treecare:/opt/dietpi-dashboard$ gdb -batch -ex "bt" ./frontend core
/opt/dietpi-dashboard/core: No such file or directory.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /opt/dietpi-dashboard/frontend.
Use `info auto-load python-scripts [REGEXP]' to list them.
No stack.

So no core dump.

Sorry, but I am getting pretty tired. I’ll be back tomorrow.

Thanks for all the help so far.

It’s important that you run the ulimit -c unlimited command, otherwise it won’t generate a core dump. It doesn’t persist between different shell sessions.

ulimit -c unlimited
./frontend
gdb -batch -ex "bt" ./frontend core

OK Getting somewhere at last. Coredumps need the package systemd-coredump to be installed and then to list available dumps

$ sudo coredumpctl list
TIME                          PID  UID  GID SIG     COREFILE EXE                             SIZE
Fri 2025-10-24 11:29:08 BST 11837 1000 1000 SIGSEGV present  /opt/dietpi-dashboard/frontend 55.3K

And to examine the dump

$ sudo coredumpctl list
TIME                          PID  UID  GID SIG     COREFILE EXE                             SIZE
Fri 2025-10-24 11:29:08 BST 11837 1000 1000 SIGSEGV present  /opt/dietpi-dashboard/frontend 55.3K
dietpi@MF-Treecare:/opt/dietpi-dashboard$ sudo coredumpctl debug /opt/dietpi-dashboard/frontend
           PID: 11837 (frontend)
           UID: 1000 (dietpi)
           GID: 1000 (dietpi)
        Signal: 11 (SEGV)
     Timestamp: Fri 2025-10-24 11:29:08 BST (7min ago)
  Command Line: ./frontend
    Executable: /opt/dietpi-dashboard/frontend
 Control Group: /system.slice/ssh.service
          Unit: ssh.service
         Slice: system.slice
       Boot ID: 383c878741c8400199680a4c9a136231
    Machine ID: c336522c50cf45d0b8c6f2a6d76b0795
      Hostname: MF-Treecare
       Storage: /var/lib/systemd/coredump/core.frontend.1000.383c878741c8400199680a4c9a136231.11837.1761301748000000.zst (present)
  Size on Disk: 55.3K
       Message: Process 11837 (frontend) of user 1000 dumped core.
                
                Module libgcc_s.so.1 from deb gcc-14-14.2.0-19.amd64
                Stack trace of thread 11837:
                #0  0x000055a3e273aa12 constant_time_conditional_memxor (/opt/dietpi-dashboard/frontend + 0x13aa12)
                #1  0x000055a3e273b7ec ring_core_0_17_14__x25519_ge_scalarmult_base (/opt/dietpi-dashboard/frontend + 0x13b7ec)
                #2  0x000055a3e273c80a ring_core_0_17_14__x25519_public_from_private_generic_masked (/opt/dietpi-dashboard/frontend + 0x13c80a)
                #3  0x000055a3e26c0f05 x25519_public_from_private (/opt/dietpi-dashboard/frontend + 0xc0f05)
                #4  0x000055a3e26c8bfc compute_public_key (/opt/dietpi-dashboard/frontend + 0xc8bfc)
                #5  0x000055a3e26d2284 compute_public_key (/opt/dietpi-dashboard/frontend + 0xd2284)
                #6  0x000055a3e26d23d4 start_and_complete<rustls::crypto::ring::kx::KxGroup> (/opt/dietpi-dashboard/frontend + 0xd23d4)
                #7  0x000055a3e26f335f emit_server_hello (/opt/dietpi-dashboard/frontend + 0xf335f)
                #8  0x000055a3e26f1fc7 handle_client_hello (/opt/dietpi-dashboard/frontend + 0xf1fc7)
                #9  0x000055a3e26a97b4 process_main_protocol<rustls::server::server_conn::ServerConnectionData> (/opt/dietpi-dashboard/frontend + 0xa97b4)
                #10 0x000055a3e2640bfa handshake<tokio::net::tcp::stream::TcpStream, rustls::server::server_conn::connection::ServerConnection, rustls::server::server_conn::ServerConnectionData> (/opt/dietpi-dashboard/frontend + 0x40bfa)
                #11 0x000055a3e267334b poll (/opt/dietpi-dashboard/frontend + 0x7334b)
                #12 0x000055a3e2628afd call_once<fn() -> core::result::Result<(), anyhow::Error>, ()> (/opt/dietpi-dashboard/frontend + 0x28afd)
                #13 0x000055a3e267a615 main (/opt/dietpi-dashboard/frontend + 0x7a615)
                #14 0x00007f7045f2cca8 n/a (libc.so.6 + 0x29ca8)
                #15 0x00007f7045f2cd65 __libc_start_main (libc.so.6 + 0x29d65)
                #16 0x000055a3e2624629 _start (/opt/dietpi-dashboard/frontend + 0x24629)
                
                Stack trace of thread 11838:
                #0  0x00007f7046011779 syscall (libc.so.6 + 0x10e779)
                #1  0x000055a3e272b17b _ZN3std3sys4sync7condvar5futex7Condvar12wait_timeout17ha707046d40b3165aE (/opt/dietpi-dashboard/frontend + 0x12b17b)
                #2  0x000055a3e272e3fb wait_timeout<tokio::runtime::blocking::pool::Shared> (/opt/dietpi-dashboard/frontend + 0x12e3fb)
                #3  0x000055a3e2730810 {closure#0}<tokio::runtime::blocking::pool::{impl#6}::spawn_thread::{closure_env#0}, ()> (/opt/dietpi-dashboard/frontend + 0x130810)
                #4  0x000055a3e272ad2f _ZN3std3sys3pal4unix6thread6Thread3new12thread_start17hb6e99e73da4d28f8E (/opt/dietpi-dashboard/frontend + 0x12ad2f)
                #5  0x00007f7045f95b7b n/a (libc.so.6 + 0x92b7b)
                #6  0x00007f70460137b8 n/a (libc.so.6 + 0x1107b8)
                ELF object binary architecture: AMD x86-64

GNU gdb (Debian 16.3-1) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/dietpi-dashboard/frontend...
[New LWP 11837]
[New LWP 11838]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./frontend'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055a3e273aa12 in constant_time_conditional_memxor (n=96, mask=<optimized out>, src=<optimized out>, dst=0x7ffc404d21c0)
    at /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ring-0.17.14/crypto/curve25519/../internal.h:272

warning: 272    /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ring-0.17.14/crypto/curve25519/../internal.h: No such file or directory
[Current thread is 1 (Thread 0x7f7046238880 (LWP 11837))]
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /opt/dietpi-dashboard/frontend.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) 

A quick look at the output suggests the problem is in /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ring-0.17.14/crypto/curve25519 which is apparently part of rust.

Just a guess, but could this be a bug exposed because my AMD GX-420GI CPU does not have a hardware random number generator?

cpuinfo does not show a ‘rdrand’ flag.

The ring rust crate is for generating random numbers.

ring is the library that manages all the cryptographic operations behind TLS. I will get in contact with the developer of ring to get this segfault fixed. In the meantime, could you upload a dietpi-bugreport and post the UUID here? @MichaIng and I should then be able to collate all of the relevant information about your system to help this bug be fixed as quickly as possible.

@MichaIng, I feel like we should err on the side of caution here and treat this as a potentially exploitable security vulnerability. It shows itself almost immediately and occurs in the middle of a basic constant-time operation, but the backtrace shows that it is triggered during the TLS handshake, so a crafted payload could conceivably lead to arbitrary memory access.

1 Like

UUID 46ab2c36-0cc5-4574-8b8d-07a922a9a1bc

@ravenclaw900 you have access to the bug report uploaded? If not, I can support. Just PM me