[gnutls-devel] GnuTLS | Null binder algorithm type causing segmentation fault (#1729)

[Read-only notification of GnuTLS library development activities]

Wilfred Mallawa created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1729



## Description of problem:

When `gnutls_psk_allocate_server_credentials2()` is invoked with GNUTLS_MAC_UNKNOWN. `_gnutls_mac_to_entry()` will return NULL as GNUTLS_MAC_UNKNOWN is not a `id` type in `hash_algorithms` list in `lib/algorithms/mac.c`.

Later in `server_recv_params()`, `pskcred->binder_algo` is de-referenced without a NULL check.

A simple change like diff below, fixes the segmentation fault. However, I am seeing errors from the target dmesg stating.

"[ 1551.681456] nvmet_tcp: queue 1: short read, 8 bytes missing"

Which I _think_ is a result of SHA384 being used instead of SHA256.

```
diff --git a/lib/algorithms/mac.c b/lib/algorithms/mac.c
index e6a8835a3..f6307fc4c 100644
--- a/lib/algorithms/mac.c
+++ b/lib/algorithms/mac.c
@@ -204,6 +204,7 @@ static SYSTEM_CONFIG_OR_CONST mac_entry_st hash_algorithms[] = {
          .key_size = 32,
          .block_size = 16 },
        { .name = "PBMAC1", .id = GNUTLS_MAC_PBMAC1, .placeholder = 1 },
+       { .name = "MAC-UNKNOWN", .id = GNUTLS_MAC_UNKNOWN },
        { .name = "MAC-NULL", .id = GNUTLS_MAC_NULL },
        { 0, 0, 0, 0, 0, 0, 0, 0, 0 }
```

Should `gnutls_psk_allocate_server_credentials2()` be able to accept an `GNUTLS_MAC_UNKNOWN` type? What is the best solution?

## Version of gnutls used:

Latest master.

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

N/A

## How reproducible:

Connecting from a Linux host to a Linux target using NVMe-TCP/TLS. The segfault occurs during the handshake.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1729
You're receiving this email because of your account on gitlab.com.


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