I don't particularly have a reproducer handy right now that's easy to approach; the apt code is quite complex. Recent fixes in gcc made it use the d15 register in apt code, and OpenSSL on armv8 clobbers the d15 register as part of RAND_bytes_ex() called by SSL_CTX_new()

This was previously reported as a compiler bug, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118537, but the compiler is not at fault for libcrypto clobbering the register.

I'm trying to debug more, but the issue is very strange, stepping through instructions is awkward. Stepping with next, the closest I get is between 811 and 813 of rand_lib.c's RAND_get0_public (3.4.0):

811     in ../crypto/rand/rand_lib.c
#0  RAND_get0_public (ctx=0xfffff79826c0 <default_context_int>, ctx@entry=0x0) at ../crypto/rand/rand_lib.c:811
#1  0x0000fffff7690f9c [PAC] in RAND_bytes_ex (ctx=0x0, buf=0xffffffffe9e0 "\250\343\376\367\377\377", num=1204, strength=0)
    at ../crypto/rand/rand_lib.c:382
#2  0x0000aaaaaaac6948 [PAC] in BaseHttpMethod::Loop (this=this@entry=0xffffffffef38)
    at /usr/src/apt-2.9.22/methods/basehttp.cc:692
#3  0x0000aaaaaaaa784c [PAC] in main (argv=<optimized out>) at /usr/src/apt-2.9.22/methods/http.cc:1051
813     in ../crypto/rand/rand_lib.c

(I injected an RAND_bytes() call into the code to reproduce it without TLS, normally this comes in via SSL_CTX_new).

At 811, we still have "2" in $d15, at line 813 we have "0". These are those two lines:

    rand = rand_new_drbg(ctx, primary, SECONDARY_RESEED_INTERVAL,
                         SECONDARY_RESEED_TIME_INTERVAL);
    CRYPTO_THREAD_set_local(&dgbl->public, rand);

I'm a bit at a loss because if I break at 811 and stepi instead next, the code continues running until way later - past line 813 - when it reaches the assertion and crashes. :D

Now the question is though, where is the assembler used in the random number generator and why can't I step here in gdb.