[gnutls-devel] GnuTLS | Null Pointer Dereference in `wrap_nettle_mac_fast()` via `gnutls_hmac_fast()` (#1897)

[Read-only notification of GnuTLS library development activities]

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



This report was generated with AI assistance and manually verified.

## Description of problem:

The exported API `gnutls_hmac_fast()` can dispatch to the Nettle MAC backend with `ptext == NULL` and `ptext_len > 0`. The internal backend `wrap_nettle_mac_fast()` forwards the unchecked pointer to `ctx.update()`, causing a NULL pointer read in the underlying Nettle update routine.

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

Affected code:

```text
lib/nettle/mac.c:493      ctx.update(&ctx, text_size, text)
lib/hash_int.c:210       _gnutls_mac_fast(...)
lib/crypto-api.c:803     gnutls_hmac_fast(...)
```

This is a negative-argument API robustness issue: the reproducer passes `NULL + nonzero 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=0x1 is used to select the plain Nettle 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_text.c](https://github.com/Bin-infinite/vuln-validations/blob/f47f650ccab29d5be069fe5418a8ae2a7ec23d51/gnutls/latest/%63%61%73%65%2D003/pocs/hmac_null_text.c)

The core call is:

```c
gnutls_hmac_fast(GNUTLS_MAC_SHA256, key, sizeof(key), NULL, 1, 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=0x1 \
./hmac_null_text
```

## 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 memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29
#1 nettle_sha256_update nettle-3.10.2-nofat/sha256.c:124
#2 wrap_nettle_mac_fast lib/nettle/mac.c:493
#3 _gnutls_mac_fast lib/hash_int.c:210
#4 gnutls_hmac_fast lib/crypto-api.c:803
#5 main hmac_null_text.c:22
```

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

## Expected results:

`gnutls_hmac_fast()` should reject `ptext == NULL && ptext_len > 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/1897
You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-8f3zngvizwjnituafwz6vkp14-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/b6a558b8/attachment-0001.html>