CI: ASan jobs failing intermittently in Argon2 / Blake2b

[solardiz]

Roughly since update to checkout@v5 a month ago in #5857, we started occasionally getting these failures for at least two of our asan* jobs. At first, reverting to checkout@v4 for the main asan job seemed to have helped, but not anymore.

AddressSanitizer:DEADLYSIGNAL
=================================================================
==9360==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x564f9c28ae6f bp 0x7ffeef9ce6c0 sp 0x7ffeef9ce400 T0)
==9360==The signal is caused by a READ memory access.
==9360==Hint: this fault was caused by a dereference of a high value address (see register values below).  Disassemble the provided pc to learn which register was used.
    #0 0x564f9c28ae6f in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29
    #1 0x564f9c28ae6f in blake2b_long /home/runner/work/john/john/src/blake2b_plug.c:420
    #2 0x564f9c25dd37 in argon2_fill_first_blocks /home/runner/work/john/john/src/argon2_core_plug.c:533
    #3 0x564f9c25ef00 in argon2_initialize /home/runner/work/john/john/src/argon2_core_plug.c:652
    #4 0x564f9c26c85d in argon2_ctx /home/runner/work/john/john/src/argon2_plug.c:82
    #5 0x564f9c260f37 in crypt_all._omp_fn.0 /home/runner/work/john/john/src/argon2_fmt_plug.c:343
    #6 0x7fa9cb89f976 in GOMP_parallel (/lib/x86_64-linux-gnu/libgomp.so.1+0x18976) (BuildId: be297f11b9b4baa3674f3d9e232b2a87b3abf6b2)
    #7 0x564f9c2613fe in crypt_all /home/runner/work/john/john/src/argon2_fmt_plug.c:323
    #8 0x564f9c4c9e1d in is_key_right /home/runner/work/john/john/src/formats.c:594
    #9 0x564f9c4d1f1e in fmt_self_test_body /home/runner/work/john/john/src/formats.c:1329
    #10 0x564f9c4d3036 in fmt_self_test /home/runner/work/john/john/src/formats.c:2079
    #11 0x564f9c4acd8e in benchmark_all /home/runner/work/john/john/src/bench.c:883
    #12 0x564f9c4e14c7 in john_run /home/runner/work/john/john/src/john.c:1695
    #13 0x564f9c4e14c7 in main /home/runner/work/john/john/src/john.c:2117
    #14 0x7fa9cb62a1c9  (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e)
    #15 0x7fa9cb62a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 274eec488d230825a136fa9c4d85370fed7a0a5e)
    #16 0x564f9bffc1c4 in _start (/home/runner/work/john/john/run/john+0x20c1c4) (BuildId: d6c880ba2b3d7ebd5a6e968289b013459f6f2bcc)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 in memcpy
==9360==ABORTING

[solardiz]

I think this is a false positive (memcpy deliberately over-reading, or memcpy bug, or ASan bug). The code is:

        uint8_t out_buffer[BLAKE2B_OUTBYTES];
        uint8_t in_buffer[BLAKE2B_OUTBYTES];
        TRY(blake2b_init(&blake_state, BLAKE2B_OUTBYTES));
        TRY(blake2b_update(&blake_state, outlen_bytes, sizeof(outlen_bytes)));
        TRY(blake2b_update(&blake_state, in, inlen));
        TRY(blake2b_final(&blake_state, out_buffer, BLAKE2B_OUTBYTES));
        memcpy(out, out_buffer, BLAKE2B_OUTBYTES / 2);
        out += BLAKE2B_OUTBYTES / 2;
        toproduce = (uint32_t)outlen - BLAKE2B_OUTBYTES / 2;

        while (toproduce > BLAKE2B_OUTBYTES) {
            memcpy(in_buffer, out_buffer, BLAKE2B_OUTBYTES);

Line 420 is the last memcpy above. Both buffers are of the exact size passed to memcpy.