[gnutls-devel] GnuTLS | Null Pointer Dereference in x86 Hash Fast Backend via `gnutls_hash_fast()` (#1899)

[Read-only notification of GnuTLS library development activities]

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



This report was generated with AI assistance and manually verified.

## Description of problem:

The exported API `gnutls_hash_fast()` can dispatch to the x86 SSSE3 hash backend with `ptext == NULL` and `ptext_len > 0`. The internal backend `wrap_x86_hash_fast()` forwards the unchecked input pointer to `ctx.update()`, causing a NULL pointer read in the SHA-256 block routine.

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

Affected code:

```text
lib/accelerated/x86/sha-x86-ssse3.c:357   ctx.update(&ctx, text_size, text)
lib/hash_int.c:153                        _gnutls_hash_fast(...)
lib/crypto-api.c:998                      gnutls_hash_fast(...)
```

This is a negative-argument API robustness issue: the reproducer passes `NULL + nonzero input 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: [hash_fast_null_harness.c](https://github.com/Bin-infinite/vuln-validations/blob/f47f650ccab29d5be069fe5418a8ae2a7ec23d51/gnutls/latest/%63%61%73%65%2D005/pocs/hash_fast_null_harness.c)

The core call is:

```c
gnutls_hash_fast(GNUTLS_DIG_SHA256, NULL, 64, 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 \
./hash_fast_null_harness
```

## 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 sha256_block_data_order_ssse3 lib/accelerated/x86/elf/sha256-ssse3-x86_64.s:2066
#1 x86_sha256_update lib/accelerated/x86/sha-x86-ssse3.c:160
#2 wrap_x86_hash_fast lib/accelerated/x86/sha-x86-ssse3.c:357
#3 _gnutls_hash_fast lib/hash_int.c:153
#4 gnutls_hash_fast lib/crypto-api.c:998
#5 main hash_fast_null_harness.c:21
```

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

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

## Expected results:

`gnutls_hash_fast()` should reject `ptext == NULL && ptext_len > 0` with a negative error code, such as `GNUTLS_E_INVALID_REQUEST`, before invoking backend callbacks. `digest == NULL` should also be rejected or explicitly documented if unsupported.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1899
You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-0j8t6iadr9m1rsnvvhntgc3uc-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/eb4e5f09/attachment-0001.html>