Segmentation fault in identity::ed25519::SecretKey::from_bytes on Linux

[binarybaron]

Summary

When using the identity::ed25519::SecretKey::from_bytes function from rust-libp2p in a release build on Linux (Ubuntu 24), a segmentation fault occurs. This happens during the process of deriving a libp2p identity in our project. The issue appears to be specific to Linux systems and only occurs when building in release mode.

https://github.com/UnstoppableSwap/core/blob/d4503a6e9cd9d5ec3d3faef8ff956c32875f6335/swap/src/seed.rs#L44-L49

UnstoppableSwap/core#95

Expected behavior

The identity::ed25519::SecretKey::from_bytes function should safely create a SecretKey from the provided bytes without causing a crash.

Actual behavior

The application crashes with a segmentation fault when calling identity::ed25519::SecretKey::from_bytes.

Relevant log output

GDB Backtrace:

$ rust-gdb target/release/swap
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 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 target/release/swap...
(No debugging symbols found in target/release/swap)
(gdb) core-file /var/lib/apport/coredump/core._root_testing-releases_core_target_release_swap.0.03d0badd-fe53-4c34-8e99-98a4c09445e5.3621066.733291890 
[New LWP 3621066]
[New LWP 3621067]
[New LWP 3621068]
[New LWP 3621071]
[New LWP 3621073]
[New LWP 3621070]
[New LWP 3621072]
[New LWP 3621069]
[New LWP 3621076]
[New LWP 3621077]
[New LWP 3621075]
[New LWP 3621074]
[New LWP 3621078]
warning: Section `.reg-xstate/3621066' in core file too small.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./target/release/swap list-sellers --rendezvous-point /dns4/discover.unstoppabl'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/3621066' in core file too small.
#0  0x000055b91d1471c0 in _ZN4sha26sha5123x8627sha512_compress_x86_64_avx217hacb649f105d99b90E.llvm.15251769145856391368 ()
[Current thread is 1 (Thread 0x7fe431a0c480 (LWP 3621066))]
(gdb) bt
#0  0x000055b91d1471c0 in _ZN4sha26sha5123x8627sha512_compress_x86_64_avx217hacb649f105d99b90E.llvm.15251769145856391368 ()
#1  0x000055b91d147046 in sha2::sha512::Engine512::finish ()
#2  0x000055b91d1470ff in <sha2::sha512::Sha512 as digest::fixed::FixedOutputDirty>::finalize_into_dirty ()
#3  0x000055b91d109b3c in <ed25519_dalek::secret::ExpandedSecretKey as core::convert::From<&ed25519_dalek::secret::SecretKey>>::from ()
#4  0x000055b91d0c28eb in <libp2p_core::identity::ed25519::Keypair as core::convert::From<libp2p_core::identity::ed25519::SecretKey>>::from
    ()
#5  0x000055b91c6a8f48 in swap::seed::Seed::derive_libp2p_identity ()
#6  0x000055b91c2ccbdf in <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll ()
#7  0x000055b91c369b59 in swap::cli::api::request::list_sellers::{{closure}} ()
#8  0x000055b91c3732ba in swap::cli::command::parse_args_and_apply_defaults::{{closure}} ()
#9  0x000055b91c38ebc5 in tokio::runtime::park::CachedParkThread::block_on ()
#10 0x000055b91c0010ff in tokio::runtime::context::runtime::enter_runtime ()
#11 0x000055b91c1e2f71 in swap::main ()
#12 0x000055b91c21b353 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#13 0x000055b91c1aa76d in std::rt::lang_start::{{closure}} ()
#14 0x000055b91d2cbe90 in std::rt::lang_start_internal ()
#15 0x000055b91c1e314c in main ()
(gdb) info registers
Missing register name
(gdb) disassemble
Dump of assembler code for function _ZN4sha26sha5123x8627sha512_compress_x86_64_avx217hacb649f105d99b90E.llvm.15251769145856391368:
   0x000055b91d147160 <+0>:	push   %rbp
   0x000055b91d147161 <+1>:	push   %r15
   0x000055b91d147163 <+3>:	push   %r14
   0x000055b91d147165 <+5>:	push   %r13
   0x000055b91d147167 <+7>:	push   %r12
   0x000055b91d147169 <+9>:	push   %rbx
   0x000055b91d14716a <+10>:	sub    $0x378,%rsp
   0x000055b91d147171 <+17>:	xor    %r11d,%r11d
   0x000055b91d147174 <+20>:	test   $0x1,%dl
   0x000055b91d147177 <+23>:	mov    %rsi,0x60(%rsp)
   0x000055b91d14717c <+28>:	mov    %rdi,0x58(%rsp)
   0x000055b91d147181 <+33>:	je     0x55b91d1475bf <_ZN4sha26sha5123x8627sha512_compress_x86_64_avx217hacb649f105d99b90E.llvm.15251769145856391368+1119>
   0x000055b91d147187 <+39>:	mov    %rdx,0x8(%rsp)
   0x000055b91d14718c <+44>:	mov    (%rdi),%rdx
   0x000055b91d14718f <+47>:	mov    0x8(%rdi),%r13
   0x000055b91d147193 <+51>:	mov    0x10(%rdi),%rbx
   0x000055b91d147197 <+55>:	mov    0x18(%rdi),%rcx
   0x000055b91d14719b <+59>:	mov    0x20(%rdi),%r10
   0x000055b91d14719f <+63>:	mov    0x28(%rdi),%rax
   0x000055b91d1471a3 <+67>:	vmovdqu (%rsi),%xmm0
   0x000055b91d1471a7 <+71>:	vmovdqa 0x426e81(%rip),%xmm7        # 0x55b91d56e030
   0x000055b91d1471af <+79>:	vpshufb %xmm7,%xmm0,%xmm2
   0x000055b91d1471b4 <+84>:	vpaddq 0x426e84(%rip),%xmm2,%xmm0        # 0x55b91d56e040
   0x000055b91d1471bc <+92>:	mov    0x30(%rdi),%r14
=> 0x000055b91d1471c0 <+96>:	vmovdqa %xmm0,0xf8(%rsp)
   0x000055b91d1471c9 <+105>:	vmovdqu 0x10(%rsi),%xmm0
   0x000055b91d1471ce <+110>:	vpshufb %xmm7,%xmm0,%xmm3
   0x000055b91d1471d3 <+115>:	vpaddq 0x426e75(%rip),%xmm3,%xmm0        # 0x55b91d56e050
   0x000055b91d1471db <+123>:	vmovdqa %xmm0,0x108(%rsp)
   0x000055b91d1471e4 <+132>:	vmovdqu 0x20(%rsi),%xmm0
   0x000055b91d1471e9 <+137>:	vpshufb %xmm7,%xmm0,%xmm0
   0x000055b91d1471ee <+142>:	vpaddq 0x426e6a(%rip),%xmm0,%xmm1        # 0x55b91d56e060
   0x000055b91d1471f6 <+150>:	vmovdqa %xmm1,0x118(%rsp)
   0x000055b91d1471ff <+159>:	vmovdqu 0x30(%rsi),%xmm1
   0x000055b91d147204 <+164>:	vpshufb %xmm7,%xmm1,%xmm1
   0x000055b91d147209 <+169>:	vpaddq 0x426e5f(%rip),%xmm1,%xmm5        # 0x55b91d56e070
   0x000055b91d147211 <+177>:	vmovdqu 0x40(%rsi),%xmm4
   0x000055b91d147216 <+182>:	vpshufb %xmm7,%xmm4,%xmm4
...

Possible Solution

No response

Version

We're using 0.42.2. We know this is relatively old but upgrading is a ton of work (we're on it)

Would you like to work on fixing this bug ?

Yes

[jxs]

Hi! Thanks for the report, version 0.42.2 is from more than two years ago. Can you reproduce this in a recent version?