Problem
On Azure Linux 3 with SymCrypt 103.8.0, glibc malloc-debug instrumentation causes consumers loading the SymCrypt OpenSSL provider to abort with free(): invalid pointer.
The POSIX shared module is linked with -nostdlib -nodefaultlibs -nostartfiles. Consequently, libsymcrypt.so has no DT_NEEDED entry for libc and its libc imports are unversioned:
aligned_alloc Base
free Base
malloc Base
When glibc's checked allocator is preloaded, the dynamic loader can bind aligned_alloc to libc.so.6 while binding free to libc_malloc_debug.so.0. SymCrypt then allocates and frees through different allocator implementations.
Reproducer
LD_PRELOAD=libc_malloc_debug.so.0 \
GLIBC_TUNABLES=glibc.malloc.check=1 \
python3 -c 'import ctypes; ctypes.CDLL("/path/to/libsymcrypt.so")'
The failure was observed on the released Azure Linux 3 system with SymCrypt 103.8.0 and reproduced in controlled testing with SymCrypt 103.12.1. LD_DEBUG=bindings confirms the split binding.
The same issue breaks the Azure Linux 4 guestfs-tools build when OpenSSL loads the SymCrypt provider. Its current packaging workaround disables malloc checking: microsoft/azurelinux#18715.
Validated fixes
Two independent changes prevent the failure:
- Use
posix_memalign instead of aligned_alloc: tobiasb-ms/fix-posix-allocator-interposition
- Explicitly link the generic POSIX module against libc, recording
DT_NEEDED: libc.so.6 and versioned imports: tobiasb-ms/fix-version-libc-imports
Both pass the SymCrypt test suite and an end-to-end Azure Linux guestfs-tools build and %check (124 tests, 0 failures/errors). Explicit libc linkage is the more structurally reliable fix, but its glibc requirements depend on the build sysroot.
Both changes modify content inside the module's FIPS integrity boundary and therefore require certification review.
Problem
On Azure Linux 3 with SymCrypt 103.8.0, glibc malloc-debug instrumentation causes consumers loading the SymCrypt OpenSSL provider to abort with
free(): invalid pointer.The POSIX shared module is linked with
-nostdlib -nodefaultlibs -nostartfiles. Consequently,libsymcrypt.sohas noDT_NEEDEDentry for libc and its libc imports are unversioned:When glibc's checked allocator is preloaded, the dynamic loader can bind
aligned_alloctolibc.so.6while bindingfreetolibc_malloc_debug.so.0. SymCrypt then allocates and frees through different allocator implementations.Reproducer
LD_PRELOAD=libc_malloc_debug.so.0 \ GLIBC_TUNABLES=glibc.malloc.check=1 \ python3 -c 'import ctypes; ctypes.CDLL("/path/to/libsymcrypt.so")'The failure was observed on the released Azure Linux 3 system with SymCrypt 103.8.0 and reproduced in controlled testing with SymCrypt 103.12.1.
LD_DEBUG=bindingsconfirms the split binding.The same issue breaks the Azure Linux 4 guestfs-tools build when OpenSSL loads the SymCrypt provider. Its current packaging workaround disables malloc checking: microsoft/azurelinux#18715.
Validated fixes
Two independent changes prevent the failure:
posix_memaligninstead ofaligned_alloc:tobiasb-ms/fix-posix-allocator-interpositionDT_NEEDED: libc.so.6and versioned imports:tobiasb-ms/fix-version-libc-importsBoth pass the SymCrypt test suite and an end-to-end Azure Linux guestfs-tools build and
%check(124 tests, 0 failures/errors). Explicit libc linkage is the more structurally reliable fix, but its glibc requirements depend on the build sysroot.Both changes modify content inside the module's FIPS integrity boundary and therefore require certification review.