From gnutls-devel at lists.gnutls.org Mon Jun 1 09:37:59 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 07:37:59 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Daiki Ueno marked merge request !2109 as ready -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-6dinnrmgz0b6iuw2nkbk0n3ql-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 10:01:45 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 08:01:45 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Simon Josefsson, Alexander Sosedkin, and Zolt?n Fridrich were added as reviewers. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-ag4fkrqponz0zidio30gg8e1g-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 10:35:33 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 08:35:33 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Merge request !2109 was approved by Simon Josefsson Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 Project:Branches: dueno/gnutls:wip/dueno/security-policy to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Simon Josefsson, Alexander Sosedkin, and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 10:35:29 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 08:35:29 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Simon Josefsson commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3404818215 LGTM -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3404818215 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-c7mf89es07zwufx2hfuw6b3y3-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 14:01:29 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 12:01:29 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Alexander Sosedkin commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586816 I approve the change in general, with my inline comments being mostly grammar nitpicks. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586816 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-0se7oo1dtghw2wfzcc3u3225e-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 14:01:40 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 12:01:40 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586660 > +our [issue tracker]. In case you can't use the GitLab web interface, > +you can still submit issues by sending an email to us, but only as a > +last resort; such reports requires us a special handling. s/requires us a special handling/require special handling on our side/ -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586709 > -branches which are affected. The commit message must refer to the bug > -report addressed (e.g., our issue tracker or some external issue tracker). > +* They are compiled with hardening [options][hardening-options], such s/are/should be/ for consistency with the follow-up bullet points -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586723 > +are considered insecure at certain point of time, out of scope. We do > +our best to tighten it from time to time, without sacrificing backward > +compatibility. I'm not entirely sure what this means. Is it "We do our best to tighten it from time to time, though backwards compatibility constraints limit how aggressively we can do that"? -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586739 > +## Severity ratings > + > +Our severity ratings differ from [CVSS], as CVSS scores are often missing link -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586754 > + * The difficulty is typically due to factors such as demanding > + timing constraints, specific platform prerequisites, or the > + involvement of rare options or protocols would memory pressure error paths be a good example here? -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586763 > + to exploit > + * Exploitation can lead to system compromise, often resulting in > + arbitrary code execution if that's meant to rule out reports with availability-only impact, that might benefit from less ambiguous wording -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586777 > -# Which issues are security issues > +The report should be self-contained and actionable without requiring > +us to follow any links or perform any extra actions. do we want a "reproducers would be welcome" line to stress that we both 1. appreciate having them over not having them though and 2. are interested in reports that don't come with reproducers anyway? -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405586789 > +## Disclosure > + > +We do not maintain our own disclosure window by ourselves. When to either "by ourselves" or "our own" feels redundant. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-1umafrthn1nq5zrlbrzb0thy1-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 14:01:43 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 12:01:43 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Merge request !2109 was approved by Alexander Sosedkin Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 Project:Branches: dueno/gnutls:wip/dueno/security-policy to gnutls/gnutls:master Author: Daiki Ueno Assignees: Reviewers: Simon Josefsson, Alexander Sosedkin, and Zolt?n Fridrich -- You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 14:41:16 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 12:41:16 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405761205 Thanks for the review, I've incorporated changes to address the suggestions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405761205 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-0sbv09xh5xth83jblfqoh1ziv-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 15:24:34 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 13:24:34 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: All discussions on merge request !2109 were resolved by Alexander Sosedkin https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-dlukzghd4kuejobocfwbs4bb5-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 1 15:26:27 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 01 Jun 2026 13:26:27 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 was reviewed by Alexander Sosedkin -- Alexander Sosedkin started a new discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3405973254 > system, or an unlikely configuration are not classified as > Critical impact > + * Issues only affect system availability (such as DoS) are not "Issues that only" or "Issues that affect availability exclusively" -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-73dyxe8ie5i43osmu20jzgmik-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 2 03:05:48 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Jun 2026 01:05:48 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Daiki Ueno commented on a discussion on SECURITY.md: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3408681718 > * Flaws that require authentication, local or physical access to a > system, or an unlikely configuration are not classified as > Critical impact > + * Issues only affect system availability (such as DoS) are not Thanks; fixed. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109#note_3408681718 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-75hvh2j7kwfgd6fce7kvre8xs-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 2 03:05:53 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Jun 2026 01:05:53 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: All discussions on merge request !2109 were resolved by Daiki Ueno https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-a6iz19majfez8k9srz6qr1jci-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 2 03:05:48 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 02 Jun 2026 01:05:48 +0000 Subject: [gnutls-devel] GnuTLS | SECURITY.md: update with current practices (!2109) In-Reply-To: References: Message-ID: Merge request !2109 was merged Merge request URL: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 Project:Branches: dueno/gnutls:wip/dueno/security-policy to gnutls/gnutls:master Author: Daiki Ueno Reviewers: Simon Josefsson, Alexander Sosedkin, and Zolt?n Fridrich -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2109 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-dz6v4gbhrux5narq3so2bgkfg-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 3 09:55:21 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 03 Jun 2026 07:55:21 +0000 Subject: [gnutls-devel] GnuTLS | Add registration API for KDF / PRF / TLS 1.3 HKDF backends (#1891) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/work_items/1891#note_3414973326 Hi Thomas, thank you for the suggestion. The `gnutls_crypto_*_register` family has been deprecated since 3.7.0, and for offloading crypto, our recommended path forward is to consolidate on the [PKCS#11 crypto backend](https://www.gnutls.org/manual/html_node/Using-PKCS_002311-module-as-cryptographic-backend.html). Could we collaborate on improving it instead? We've already identified several missing areas such as PQC algorithms support and RNG. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1891#note_3414973326 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-dyhrc1o7fiplcfj2u22vkoudg-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 4 20:28:14 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 18:28:14 +0000 Subject: [gnutls-devel] GnuTLS | Heap Use-After-Free in `gnutls_pkcs7_get_signature_info()` Error Cleanup (#1896) References: Message-ID: Issue created by ??? (Qi Kery): https://gitlab.com/gnutls/gnutls/-/work_items/1896 This report was generated with AI assistance and manually verified. ## Description of problem: `gnutls_pkcs7_get_signature_info()` can use a freed PKCS#7 attribute list during error cleanup. While copying signed attributes, `gnutls_pkcs7_get_signature_info()` calls: ```c ret = gnutls_pkcs7_add_attr(&info->signed_attrs, oid, &tmp, 0); ``` If `gnutls_pkcs7_add_attr()` fails after `*list` already contains entries, its failure path calls `gnutls_pkcs7_attrs_deinit(*list)` but does not set `*list` to `NULL`. Control then returns to `gnutls_pkcs7_get_signature_info()`, which reaches its `fail:` label and calls `gnutls_pkcs7_signature_info_deinit(info)`. That cleanup path traverses `info->signed_attrs`, which still points to freed memory. Affected code: ```text lib/x509/pkcs7.c:702 gnutls_pkcs7_add_attr(&info->signed_attrs, ...) lib/x509/pkcs7.c:751 gnutls_pkcs7_signature_info_deinit(info) lib/x509/pkcs7-attrs.c:86 gnutls_pkcs7_attrs_deinit(*list) ``` ## 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 attached/local harness and FAIL_AFTER=9. The same harness exits successfully when FAIL_AFTER is not set. ``` 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 /lib/.libs/libgnutls.so.30.42.0 SHA-256: 224c60682088ac07680c1eba04acd159b51bd8995bedcbc1fc288fe248a1058b ``` * Compile the reproducer: Reproducer source: [pkcs7_siginfo_fail_harness.c](https://github.com/Bin-infinite/vuln-validations/blob/f47f650ccab29d5be069fe5418a8ae2a7ec23d51/gnutls/latest/%63%61%73%65%2D002/pocs/pkcs7_siginfo_fail_harness.c) This harness builds a valid PKCS#7 object with signed attributes using GnuTLS APIs, imports it, and installs allocator wrappers only for the target call. * 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' \ FAIL_AFTER=9 \ ./pkcs7_siginfo_fail_harness ``` ## Actual results: ASan reports a heap-use-after-free: ```text ERROR: AddressSanitizer: heap-use-after-free READ of size 8 #0 gnutls_pkcs7_attrs_deinit lib/x509/pkcs7-attrs.c:152 #1 gnutls_pkcs7_signature_info_deinit lib/x509/pkcs7.c:483 #2 gnutls_pkcs7_get_signature_info lib/x509/pkcs7.c:751 freed by thread T0 here: #1 gnutls_pkcs7_attrs_deinit lib/x509/pkcs7-attrs.c:156 #2 gnutls_pkcs7_add_attr lib/x509/pkcs7-attrs.c:86 #3 gnutls_pkcs7_get_signature_info lib/x509/pkcs7.c:702 previously allocated by thread T0 here: #1 gnutls_pkcs7_add_attr lib/x509/pkcs7-attrs.c:59 #2 gnutls_pkcs7_get_signature_info lib/x509/pkcs7.c:702 ``` Full log: [fail_after_9_run1.stderr.txt](https://github.com/Bin-infinite/vuln-validations/blob/f47f650ccab29d5be069fe5418a8ae2a7ec23d51/gnutls/latest/%63%61%73%65%2D002/runs/fail_after_9_run1.stderr.txt) ## Expected results: `gnutls_pkcs7_get_signature_info()` should return a negative error code without using a freed attribute list. The ownership contract should be made consistent. For example, `gnutls_pkcs7_add_attr()` could set `*list = NULL` after freeing the existing list, or avoid destructively freeing the caller's existing list on failure. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1896 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-4v51n0fhb6dh4c278kxr883vj-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 4 20:30:00 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 18:30:00 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in `wrap_nettle_mac_fast()` via `gnutls_hmac_fast()` (#1897) References: Message-ID: 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 /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: From gnutls-devel at lists.gnutls.org Thu Jun 4 20:30:36 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 18:30:36 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in x86 HMAC Fast Backend via `gnutls_hmac_fast()` (#1898) References: Message-ID: 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 /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: From gnutls-devel at lists.gnutls.org Thu Jun 4 20:31:15 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 18:31:15 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in x86 Hash Fast Backend via `gnutls_hash_fast()` (#1899) References: Message-ID: 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 /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: From gnutls-devel at lists.gnutls.org Fri Jun 5 01:56:07 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 23:56:07 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in `wrap_nettle_mac_fast()` via `gnutls_hmac_fast()` (#1897) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/work_items/1897#note_3424212659 > `gnutls_hmac_fast(GNUTLS_MAC_SHA256, key, sizeof(key), NULL, 1, digest);` This is an API mis-use, which is out of scope of our threat model: https://gitlab.com/gnutls/gnutls/-/blob/master/SECURITY.md?ref_type=heads#threat-model If we were to address it, that would be adding an `assert` to be clear that it is a programming error of the application. Please stop reporting issues in this class of problems. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1897#note_3424212659 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-7t0uol693f10is4mgw9m11pux-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 5 01:56:05 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 23:56:05 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in `wrap_nettle_mac_fast()` via `gnutls_hmac_fast()` (#1897) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1897: https://gitlab.com/gnutls/gnutls/-/work_items/1897 -- 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-0ltcmapffl0iggkzmpym6tu3x-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 5 01:58:37 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 23:58:37 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in x86 HMAC Fast Backend via `gnutls_hmac_fast()` (#1898) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1898: https://gitlab.com/gnutls/gnutls/-/work_items/1898 -- 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-bq7md7ul3w2p04yd8ht70paxe-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 5 01:58:38 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 04 Jun 2026 23:58:38 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in x86 HMAC Fast Backend via `gnutls_hmac_fast()` (#1898) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/work_items/1898#note_3424215749 > `gnutls_hmac_fast(GNUTLS_MAC_SHA1, NULL, 16, text, sizeof(text), digest);` This is an API mis-use, which is out of scope of our threat model: https://gitlab.com/gnutls/gnutls/-/blob/master/SECURITY.md?ref_type=heads#threat-model If we were to address it, that would be adding an `assert` to be clear that it is a programming error of the application. Please stop reporting issues in this class of problems. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1898#note_3424215749 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-92ga6aqmocjve8t5u5l9e1bwf-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 5 02:01:09 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Jun 2026 00:01:09 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in x86 Hash Fast Backend via `gnutls_hash_fast()` (#1899) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1899: https://gitlab.com/gnutls/gnutls/-/work_items/1899 -- 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-5dwdog33m6bca0umum1svvczx-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Jun 5 02:02:32 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Fri, 05 Jun 2026 00:02:32 +0000 Subject: [gnutls-devel] GnuTLS | Null Pointer Dereference in x86 Hash Fast Backend via `gnutls_hash_fast()` (#1899) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/work_items/1899#note_3424218379 > `gnutls_hash_fast(GNUTLS_DIG_SHA256, NULL, 64, digest);` This is an API mis-use, which is out of scope of our threat model: https://gitlab.com/gnutls/gnutls/-/blob/master/SECURITY.md?ref_type=heads#threat-model If we were to address it, that would be adding an `assert` to be clear that it is a programming error of the application. Please stop reporting issues in this class of problems. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1899#note_3424218379 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-33j0odg273gnxdiiwmrix8bd4-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Jun 7 09:33:06 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 07 Jun 2026 07:33:06 +0000 Subject: [gnutls-devel] GnuTLS | Behavioral PKCS#1 v1.5 decryption oracle (Ok/Err bit) (#1901) References: Message-ID: Issue created by Mark Esler: https://gitlab.com/gnutls/gnutls/-/work_items/1901 Hello, While surveying PKCS#1 v1.5 implementations [0] for the behavioral Bleichenbacher oracle [1] I found that GnuTLS exposes the oracle through its callable decrypt API. `gnutls_privkey_decrypt_data` / `gnutls_privkey_decrypt_data2` returns `GNUTLS_E_DECRYPTION_FAILED` on a non-conforming block and succeeds otherwise ? a distinguishable bit. `_data2` is documented constant-time but that is constant-time *explicit* rejection, not implicit rejection; the behavioral bit remains. The oracle is closed inside the TLS key-exchange path (result discarded) but not for general callers (JOSE / CMS / PKCS#11 / direct decrypt). Runtime-confirmed, source-reviewed in `lib/privkey.c` and `lib/pk.c`. The CFRG implementation guidance draft [2] covers remediation: OAEP as the fix, implicit rejection (?7.2) as the stopgap if v1.5 must stay. Mark Esler [0] https://hexproof.dev/datagrams/bleichenbacher-oracle-survey/ [1] https://hexproof.dev/datagrams/ok-err-is-a-padding-oracle/ [2] https://datatracker.ietf.org/doc/draft-irtf-cfrg-rsa-guidance/ -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1901 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-cgo0u1rjctmrc5yb71ioqn75l-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Jun 7 09:36:43 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 07 Jun 2026 07:36:43 +0000 Subject: [gnutls-devel] GnuTLS | Behavioral PKCS#1 v1.5 decryption oracle (Ok/Err bit) (#1901) In-Reply-To: References: Message-ID: Mark Esler commented: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3430218120 I believe I set `Turn on confidentiality: Limit visibility to project members with at least the Planner role.` when creating this issue in accordance with https://www.gnutls.org/security.html I can see this issue from https://gitlab.com/gnutls/gnutls/-/work_items so I either _didn't_ select it or GnuTLS has permissive settings (?) Apologize if on my end. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3430218120 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-1nm4hq2fr1z8e77y18g1iitg6-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 8 01:50:10 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Sun, 07 Jun 2026 23:50:10 +0000 Subject: [gnutls-devel] GnuTLS | Behavioral PKCS#1 v1.5 decryption oracle (Ok/Err bit) (#1901) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3430852743 Although the implicit rejection guidance is less error-prone for the applications, it is possible to write a safe application with the explicit rejection API, as we do in RSA key exchange in the library (see #1050 and co.). Therefore I don't consider this a security issue but an enhancement request to provide an implicit rejection API. cc @tomato42 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3430852743 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-8n4u9cnuv8p79p5p0t40j65n0-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Jun 8 11:36:50 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Mon, 08 Jun 2026 09:36:50 +0000 Subject: [gnutls-devel] GnuTLS | gnutls_certificate_verify_peers2() does not seem to verify ExtendedKeyUsage (#1886) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/work_items/1886#note_3431977245 I agree that the `_verify_peers2` documentation is a bit unclear; it should either direct the users to `_verify_peers` or have a dedicated function to limit key purposes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1886#note_3431977245 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-6m7lzul2ilo4h9hb9jm4c83kg-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 9 12:01:18 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Jun 2026 10:01:18 +0000 Subject: [gnutls-devel] GnuTLS | Behavioral PKCS#1 v1.5 decryption oracle (Ok/Err bit) (#1901) In-Reply-To: References: Message-ID: Alicja Kario (@mention me if you need reply) commented: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3436648783 Sorry @eslerm, I remembered that we fixed it, I misremembered how we fixed it in GnuTLS. Yes, the API in GnuTLS can be used securely, it's just hard to do. Implicit rejection would be nice for calling applications but given that RSA PKCS#1v1.5 encryption is on the way out, it may be better to remove it than to add implicit rejection. So, I agree on triaging it as a enhancement. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3436648783 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-4lvle22pkqwkvpabn8b44aydx-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Jun 9 19:05:43 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Tue, 09 Jun 2026 17:05:43 +0000 Subject: [gnutls-devel] GnuTLS | Tautological assertion in pkcs11-mock4.c never validates initialization flags (#1902) References: Message-ID: Issue created by swathipanneerselvam: https://gitlab.com/gnutls/gnutls/-/work_items/1902 ## Description of problem: In tests/pkcs11/pkcs11-mock4.c (added in MR !2041 for CVE-2025-9820), the assertion checking C_Initialize flags is a no-op due to C operator precedence: c assert(!(init_args->flags & LOCK_FLAGS) != LOCK_FLAGS); ! binds tighter than !=, so this evaluates as (0 or 1) != LOCK_FLAGS ? always true since LOCK_FLAGS is a multi-bit constant. The mock never actually validates the initialization behavior. Fix should be either: c assert(!(init_args->flags & LOCK_FLAGS)); or: c assert((init_args->flags & LOCK_FLAGS) != LOCK_FLAGS); ## Version of gnutls used: 3.8.10 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Amazon Linux 2023 (found while rebasing from c9s) ## How reproducible: Always ? the assertion is a compile-time tautology. Steps to Reproduce: * Build gnutls 3.8.10 with the CVE-2025-9820 patch applied * Run the pkcs11/long-label test * Observe that the assertion in override_C_Initialize passes regardless of what flags the caller sets ## Actual results: Assertion always passes. The mock accepts any combination of initialization flags without validating. ## Expected results: Assertion should fail if the caller passes unexpected flags, validating the expected 3.8.10 C_Initialize behavior as the comment in the code describes. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1902 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-dnoxcqatf8ycow6mh1tsu8q41-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 10 02:41:22 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Jun 2026 00:41:22 +0000 Subject: [gnutls-devel] GnuTLS | Tautological assertion in pkcs11-mock4.c never validates initialization flags (#1902) In-Reply-To: References: Message-ID: Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/work_items/1902#note_3439652475 > `assert(!(init_args->flags & LOCK_FLAGS) != LOCK_FLAGS);` The upstream code never had this; those asserts were introduced in CentOS Stream 9 when backporting: https://gitlab.com/redhat/centos-stream/rpms/gnutls/-/blob/b0f3d6f1b736169d26b3ba645773762b202c3d31/gnutls-3.8.10-CVE-2025-9820.patch#L120 Could you report it there: https://docs.centos.org/centos-stream-docs/bugs/ I'm closing this as invalid. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1902#note_3439652475 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-b09d3gjhrfrjpzogf1qrqpxt0-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Jun 10 02:41:42 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Wed, 10 Jun 2026 00:41:42 +0000 Subject: [gnutls-devel] GnuTLS | Tautological assertion in pkcs11-mock4.c never validates initialization flags (#1902) In-Reply-To: References: Message-ID: Issue was closed by Daiki Ueno Issue #1902: https://gitlab.com/gnutls/gnutls/-/work_items/1902 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1902 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-3i52oteozvkl6r5jppebumpju-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Jun 11 07:03:01 2026 From: gnutls-devel at lists.gnutls.org (Read-only notification of GnuTLS library development activities) Date: Thu, 11 Jun 2026 05:03:01 +0000 Subject: [gnutls-devel] GnuTLS | Behavioral PKCS#1 v1.5 decryption oracle (Ok/Err bit) (#1901) In-Reply-To: References: Message-ID: Mark Esler commented: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3444450399 Cheers for the triage @dueno and @tomato42 ? And nice fix on the timing channel in #1050. (Alicja, I'd filed this before we spoke and hadn't seen 1050 at the time, overlap's on me.) Agree that it can be used safety. If an attacker has access to the behavioral (Ok/Err) oracle, against a 4096-bit key it takes ~40k decrypt queries to recover a plaintext and ~110k to forge a signature. Enhancement + removal sounds good to me. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/work_items/1901#note_3444450399 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/sent_notifications/5-dulmsuzrji4oqfkcqs29hoyn9-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help -------------- next part -------------- An HTML attachment was scrubbed... URL: