|
From: Paul F. <pj...@wa...> - 2024-11-16 08:22:41
|
On 15-11-24 08:34, Mathew T wrote:
> Hello,
>
> I’m seeking assistance with a challenging issue involving an
> executable on an ARM64 Ubuntu system. Here’s the problem and what I’ve
> done to investigate it so far:
>
> Problem Summary: I have an ARM64 executable that crashes with a
> segmentation fault(early to main function, looks like when loading .so
> libraries) when run independently. However, when running it with
> Valgrind, the program completes its execution, although Valgrind does
> report an Invalid free error.
Can you share the source? Even a cut down reproducer?
I've had a quick look at the openssl code. Maybe not the same as your
version.
void BN_clear_free(BIGNUM *a)
{
if (a == NULL)
return;
if (a->d != NULL && !BN_get_flags(a, BN_FLG_STATIC_DATA))
bn_free_d(a, 1);
if (BN_get_flags(a, BN_FLG_MALLOCED)) {
OPENSSL_cleanse(a, sizeof(*a));
OPENSSL_free(a);
}
}
It looks BIGNUM has a member 'd' that actually points to the allocated
block. I also presume that at the point of failure 'a' is valid and that
its flags field is also OK.
bn_free_d is probably inlined. I don't see why we don't see the CRYPTO
function in the callstack. Maybe that's not always used?
>
> Valgrind Output (partial):
> ===================
> plaintext
> Copy code
> ==2644== Invalid free() / delete / delete[] / realloc()
> ==2644== at 0x7127AD0: free (in
> /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
> ==2644== by 0x838C0CB: BN_clear_free (in
> /usr/lib/aarch64-linux-gnu/libcrypto.so.3)
> ==2644== by 0x7B8CEAB: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644== by 0x7B9121F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644== by 0x7B7DF3F: ??? (in /usr/lib/aarch64-linux-gnu/libssh.so.4.8.7)
> ==2644== by 0x68C5623: call_init (dl-init.c:70)
> ==2644== by 0x68C5623: call_init (dl-init.c:26)
> ==2644== by 0x68C572B: _dl_init (dl-init.c:117)
> ==2644== by 0x68D7CC7: ??? (in
> /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1)
> ==2644== Address 0x1 is not stack'd, malloc'd or (recently) free'd
This looks like it's happening before main _dl_init. ld.so loads shared
libraries and runs any global init code (like C++ constructors).
> Additional Information:
> ====================
> The crash appears to be related to libcrypto and libssh libraries.
> libssh.so.4 and libcrypto.so.3 versions on the system match the
> versions the executable was compiled against.
> I have attempted to gather debug symbols for these libraries to
> analyze further, but only limited information is available from the
> system-provided packages.
Getting debuginfo would help.
> Questions:
> =========
> 1. Could the difference in behavior (running under Valgrind vs.
> standalone) indicate a specific type of issue, such as a memory
> alignment problem?
The memory layout is different when running under valgrind. Mainly the
stack is in a different place. Allocation alignment is probably the same.
> 2. Are there recommended methods or tools, other than Valgrind and
> GDB, that might help debug memory management issues specifically on
> ARM64?
Sanitizers?
> 3. Has anyone encountered similar issues when libcrypto or libssh
> functions are involved?
No, I don't use Linux arm64 much.
A+
Paul
|