[gnutls-devel] GnuTLS | Null Pointer Dereference in x86 HMAC Fast Backend via `gnutls_hmac_fast()` (#1898)

Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Thu Jun 4 20:30:36 CEST 2026



Issue created by Kery: https://gitlab.com/gnutls/gnutls/-/work_items/1898



This report was generated with AI assistance and manually verified.

## Description of problem:

The exported API `gnutls_hmac_fast()` can dispatch to the x86 SSSE3 HMAC backend with `key == NULL` and `keylen > 0`. The internal backend `wrap_x86_hmac_fast()` forwards the unchecked key pointer to `ctx.setkey()`, causing a NULL pointer read.

The harness calls the exported `gnutls_hmac_fast()` API. It does not directly call the internal static function.

Affected code:

```text
lib/accelerated/x86/hmac-x86-ssse3.c:280   ctx.setkey(&ctx, key_size, key)
lib/hash_int.c:201                         _gnutls_mac_fast(...)
lib/crypto-api.c:803                       gnutls_hmac_fast(...)
```

This is a negative-argument API robustness issue: the reproducer passes `NULL + nonzero key length`.

## Version of gnutls used:

```text
Upstream origin/master
Commit: 0b9fcb47c734191695b7b7812a0ba30a5c712b9f
Commit date: 2026-06-02 10:05:44 +0900
Configure summary version: 3.8.13 shared 72:0:42
```

## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)

```text
Upstream source build, not a distribution package.
Built locally on Ubuntu with glibc 2.39.
```

## How reproducible:

```text
Always reproducible with the harness when GNUTLS_CPUID_OVERRIDE=0x4 is used to select the x86 SSSE3 backend.
```

Steps to Reproduce:

 * Build GnuTLS from the commit above with hardening and sanitizers:

```text
CPPFLAGS=-D_FORTIFY_SOURCE=3
CFLAGS=-O2 -g -fno-omit-frame-pointer -fsanitize=address,undefined -fstack-protector-strong -fPIE
LDFLAGS=-fsanitize=address,undefined -Wl,-z,relro -Wl,-z,now -pie
```

The verified library was:

```text
<build-dir>/lib/.libs/libgnutls.so.30.42.0
SHA-256: 224c60682088ac07680c1eba04acd159b51bd8995bedcbc1fc288fe248a1058b
```

 * Compile the reproducer:

Reproducer source: [hmac_null_poc.c](https://github.com/Bin-infinite/vuln-validations/blob/f47f650ccab29d5be069fe5418a8ae2a7ec23d51/gnutls/latest/%63%61%73%65%2D004/pocs/hmac_null_poc.c)

The core call is:

```c
gnutls_hmac_fast(GNUTLS_MAC_SHA1, NULL, 16, text, sizeof(text), digest);
```

 * Run the reproducer:

```bash
ASAN_OPTIONS='abort_on_error=1:symbolize=1:detect_leaks=0:allocator_may_return_null=1' \
UBSAN_OPTIONS='halt_on_error=0:print_stacktrace=1' \
LSAN_OPTIONS='detect_leaks=0' \
GNUTLS_CPUID_OVERRIDE=0x4 \
./hmac_null_poc key-null
```

## Actual results:

ASan reports a NULL read:

```text
ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
The signal is caused by a READ memory access.
#0 nettle_memxor nettle-3.10.2-nofat/memxor.s:164
#1 wrap_x86_hmac_fast lib/accelerated/x86/hmac-x86-ssse3.c:280
#2 _gnutls_mac_fast lib/hash_int.c:201
#3 gnutls_hmac_fast lib/crypto-api.c:803
#4 main hmac_null_poc.c
```

The same run also emits a UBSan function-pointer type diagnostic at the backend call site before ASan reports the NULL read.

Full log: [hmac_key_null_run1.stderr.txt](https://github.com/Bin-infinite/vuln-validations/blob/f47f650ccab29d5be069fe5418a8ae2a7ec23d51/gnutls/latest/%63%61%73%65%2D004/runs/hmac_key_null_run1.stderr.txt)

## Expected results:

`gnutls_hmac_fast()` should reject `key == NULL && keylen > 0` with a negative error code, such as `GNUTLS_E_INVALID_REQUEST`, before invoking backend callbacks. Related NULL argument combinations should be validated centrally so all MAC providers behave consistently.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1898
You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-6gv0gi0repn03bw1cy2iz30zu-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20260604/af2decbb/attachment-0001.html>


More information about the Gnutls-devel mailing list