dmesg shows segfaults in openssl.Linux.x86_64 " ... error 14 in openssl.Linux.x86_64[400000+3b9000] likely on CPU 0 (core 0, socket 0)" #2607
Labels
3.2
upcoming release
Comments
|
Hi, yes, it is still a thing some under some distributions / constellations. Personally I wasn't able to reproduce that but there are other issues filed here. Don't know whether yours is related. Atm it's better to use the version from your vendor or just compile the one this project uses for yourself. There's no difference in the result though. What puzzles me that you weren't getting any segfaults on the terminal? |
Thanks ... works ... no dmesg segfaults!
No, nothing in the testssl terminal with the plain |
Cool! How did you compile it, statically or dynamically?
Reason why I asked is, It would be great to know where the segfaults occurred. Could you do like |
Just result |
That results in a 30MB file, without "segfault" in it. What should I look at? Or should I upload it somewhere? Notes:
|
|
As said earlier: the demsg segfaults happen immediatly after starting testssl.sh When I start with |
I sense a DNS problem. Strange that the debug output is empty. Weak try: |
|
BTW: Can I still say "Guten Rutsch", or am I too late for that? I did this: Both generate segfaults in dmesg. Directories are there, with a lot of files in there. But nothing if I search on these words:
Note: I don't want to take too much of your time on this, so if you have higher prio's that's OK with me. |
|
Two last tries:
For the 3.2 release I'd like to recompile the supplied openssl-bad statically and provide it. That's why I'd like to understand what's happening. Similar problems were mostly NSS/DNS related. If it's something else, it would be great to know beforehand. |
|
Your try 1: Seems not good? But ... Nothing in dmesg. Let's try with the self-compiled openssl-1.0.2.bad (in another directory) ... looks better? |
|
Your try 2 (I had to remove the one single-quote ... I hope that's correct). See long output below. And that generates the segfaults in dmesg. In /tmp |
|
Thanks! Some comments and questions: a) The problem encountered so far were related to the static binary. And being static was a part of the problem. The binaries I supplied were compiled under a very old Ubuntu distro. Probably that was part of the prolem b) The c) Try 1 should be rather |
|
After a fresh ... no segfault in the temp dir: |
|
@sanderjo : the segfault is supposed to be in |
|
Altered Try 1: with in dmesg: That's nice (I think?) No problem with "127.0.0.1" below. NOTE: my issue report is about running |
Nothing, AFAIK |
|
in the meatime I was able to reproduce it under debian 12 when running dmesg shows the same as for you Error 14 is a page fault. So either the loader or openssl trries to execute code where it is not mapped (https://utcc.utoronto.ca/~cks/space/blog/linux/KernelSegfaultErrorCodes). |
So ... provide a more recent openssl binary for newer Linux versions? Or the newev version as default, and provide older binary for older Linux versions? |
|
I'll recompile a POC first under a newer distro ASAP. There's also a backport which needs to be done: testssl/openssl-1.0.2.bad#2 |
|
FYI: A static binary complied under Ubuntu 20.04 shows the same problem under Debian 12 and as reported from you. |
|
A new binary which is meant for testing is @ https://testssl.sh/openssl-1.0.2k-bad/openssl.Linux.x86_64.static . It was compiled under Ubuntu 2204. Hope it works also for older distros. The backport for sieve is missing as mentioned in testssl/openssl-1.0.2.bad#2 + #2356 . If it doesn't work, please let me know. |
|
Yes, works, without segfaults in dmesg! and then
This is on my Ubuntu 24.04. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version:
When running testssl against my local (=on same machine) webserver (cherrypy/cheroot, with self-signed certificate), testssl shows a bad grade (as expected), but the interesting part: dmesg shows segfaults in openssl.Linux.x86_64. It happens quite early in the testssl process
Test 2
When I run testssl against a lookalike webserver (cherrypy/cheroot, with self-signed certificate) on another machine on my LAN, the same dmesg errors occur on the machine running testssl (no messages on the remote machine).
So it's a thing on the machine running testssl?
Test 3
Ah, interesting: Based on #1934 (comment)
No demsg segfaults with `./testssl.sh --openssl=/usr/bin/openssl 127.0.0.1:8080
`
So:
Ubuntu 24.04, fully updated.
Looks a bit like #1275
The text was updated successfully, but these errors were encountered: