Unversioned libc imports can split allocator bindings under interposition #62

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:

1. Use posix_memalign instead of aligned_alloc: tobiasb-ms/fix-posix-allocator-interposition
2. 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.