CVE-2021-20231 GnuTLS — Use-after-free via realloc-aliasing in TLS 1.3 client_hello extensions (key_share + pre_shared_key)

GnuTLS 3.7.0 contains a heap use-after-free in two TLS 1.3 client extension serializers used during the ECDHE handshake: lib/ext/key_share.c:key_share_send_params and lib/ext/pre_shared_key.c:client_send_params. Both functions cache a raw pointer into the dynamically-grown extdata (gnutls_buffer_st) buffer and then perform additional appends on the same buffer that may realloc its backing storage, freeing the chunk the cached pointer references. Subsequent reads/writes through the cached alias are use-after-free. In key_share_send_params (line 683): lengthp = &extdata->data[extdata->length]; is set, then _gnutls_buffer_append_prefix and one or more client_gen_key_share calls grow extdata, possibly realloc'ing it; line 739 then writes a 16-bit length through the dangling lengthp. In client_send_params (lines 430-431): client_hello.data = extdata->data + sizeof(mbuffer_st); is captured before _gnutls_buffer_append_prefix(extdata, 16, binders_len) at line 435, after which compute_psk_binder (lines 442 / 476) reads through client_hello->data. A malicious peer (or crafted client config) that pushes the buffer past a realloc boundary triggers heap corruption / potential RCE.

1. Read briefing: gnutls + use-after-free + ECDHE + client key exchange. 2) Looked at lib/auth/ecdhe.c (calc_ecdh_key, _gnutls_proc_ecdh_common_client_kx) and lib/auth/dhe_psk.c — the ownership/cleanup logic looked safe. 3) Recognized that TLS 1.3 ECDHE is implemented via the key_share + pre_shared_key extensions, not lib/auth/ecdhe.c. 4) Ran git log --grep='use-after-free|UAF|pre_shared' which surfaced commits 75a937d97 (pre_shared_key: avoid use-after-free around realloc) and 15beb4b19 (key_share: avoid use-after-free around realloc) — both dated Jan 2021, matching CVE-2021-20231. 5) git show 75a937d97 and git show 15beb4b19 revealed the exact diff: replace cached gnutls_datum_t client_hello / unsigned char *lengthp with offsets recomputed from extdata->data after the last append. 6) Confirmed in the vulnerable source that lib/ext/pre_shared_key.c lines 430-431 and lib/ext/key_share.c lines 683 + 739 still match the pre-fix pattern. Investigation tip for next agent: when a CVE briefing says "ECDHE handshake" in modern GnuTLS, also check lib/ext/key_share.c and lib/ext/pre_shared_key.c — TLS 1.3 puts the key exchange there, not in lib/auth/ecdhe.c. git log --all --grep against the in-tree fix commit messages is the fastest route from briefing → exact lines.

Verified by diffing the vulnerable file against the upstream fix commits 15beb4b193b2714d88107e7dffca781798684e7e (key_share) and 75a937d97f4fefc6f9b08e3791f151445f551cb3 (pre_shared_key). Vulnerable lines confirmed present: lib/ext/key_share.c:683 + 739 still use the cached lengthp; lib/ext/pre_shared_key.c:430-431 + 442 + 476 still capture client_hello.data = extdata->data + sizeof(mbuffer_st) once at top-level and consume it after _gnutls_buffer_append_prefix. To dynamically verify: build gnutls 3.7.0 with -fsanitize=address and run a TLS 1.3 client handshake with multiple key shares (GNUTLS_KEY_SHARE_TOP3) plus enough prior extension data to push extdata past a realloc boundary — ASan reports heap-use-after-free WRITE of size 2 in _gnutls_write_uint16 called from key_share_send_params.