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

[Read-only notification of GnuTLS library development activities]

Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/issues/1729#note_2684492595


Thank you for spotting this, @twilfredo. I would change `server_recv_params` to treat `pskcred->binder_algo == NULL` for auto-detection, rather than introducing a new MAC entry for UNKNOWN. Something like the following might work, though we probably need a unit test for that:
```diff
diff --git a/lib/ext/pre_shared_key.c b/lib/ext/pre_shared_key.c
index d709efa74b..0f40d81de8 100644
--- a/lib/ext/pre_shared_key.c
+++ b/lib/ext/pre_shared_key.c
@@ -886,9 +886,9 @@ retry_binder:
 			gnutls_psk_key_flags flags;
 			uint8_t ipsk[MAX_HASH_SIZE];
 
-			prf = pskcred->binder_algo;
-			if (prf->id == GNUTLS_MAC_UNKNOWN)
-				prf = _gnutls_mac_to_entry(mac);
+			prf = pskcred->binder_algo == NULL ?
+				_gnutls_mac_to_entry(mac) :
+				pskcred->binder_algo;
 
 			/* this fails only on configuration errors; as such we always
 			 * return its error code in that case */
@@ -983,7 +983,7 @@ retry_binder:
 		 * even for SHA384 PSKs, so we need to retry with SHA256
 		 * to calculate the correct binder value for those.
 		 */
-		if (prf->id == GNUTLS_MAC_UNKNOWN && mac == GNUTLS_MAC_SHA384) {
+		if (pskcred->binder_algo == NULL && mac == GNUTLS_MAC_SHA384) {
 			mac = GNUTLS_MAC_SHA256;
 			goto retry_binder;
 		}
```
cc @hare1712

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1729#note_2684492595
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/20250813/77d04e53/attachment-0001.html>