CVE-2025-32988
Description
A flaw was found in GnuTLS. A double-free vulnerability exists in GnuTLS due to incorrect ownership handling in the export logic of Subject Alternative Name (SAN) entries containing an otherName. If the type-id OID is invalid or malformed, GnuTLS will call asn1_delete_structure() on an ASN.1 node it does not own, leading to a double-free condition when the parent function or caller later attempts to free the same structure.
This vulnerability can be triggered using only public GnuTLS APIs and may result in denial of service or memory corruption, depending on allocator behavior.
Statement
This vulnerability is rated Moderate rather than Important because, although it involves a memory management flaw (double-free) that can potentially lead to memory corruption, practical exploitation is limited by modern memory protection mechanisms and contextual constraints. The issue occurs only when processing malformed SAN otherName entries through public GnuTLS APIs—an uncommon and controlled code path in most deployments. Furthermore, exploitation for arbitrary code execution is highly dependent on allocator behavior and requires precise heap manipulation, which is non-trivial under defenses such as Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), and hardened memory allocators. In the majority of cases, the outcome would be a crash or denial of service rather than a reliable compromise of integrity or confidentiality. Therefore, given its limited attack surface, dependency on crafted input, and the presence of strong runtime mitigations, the impact justifies a Moderate severity classification instead of Important.
As such, successfully triggering this vulnerability would require a sophisticated attack vector that is capable of accounting for the many native and deployed security mechanisms designed to detect and contain a double-free condition.
Mitigation
Currently, no mitigation is available for this vulnerability.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 6.5 | 8.2 | 6.5 |
| Attack Vector | Network | Network | Network |
| Attack Complexity | High | Low | High |
| Privileges Required | None | None | None |
| User Interaction | None | None | None |
| Scope | Unchanged | Unchanged | Unchanged |
| Confidentiality | None | None | None |
| Integrity Impact | Low | Low | Low |
| Availability Impact | High | High | High |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
NVD: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
cve.org: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
Red Hat CVSS v3 Score Explanation
Attack complexity is high because an attacker must supply a very specific, malformed SAN otherName that actually reaches the vulnerable code path, then reliably turn a double-free into meaningful memory corruption — a process that depends on the target’s heap allocator (glibc, jemalloc, etc.), its version and configuration, and the application’s allocation patterns; achieving that typically requires careful heap grooming to force reused chunks into attacker-controlled data, plus bypassing modern defenses (safe-linking/quarantine, ASLR, DEP/NX, hardened unlinking and stack canaries) and often additional information-leak primitives or secondary bugs, so exploitation is highly environment-specific, non-deterministic, and requires substantial expertise and trial-and-error rather than a simple, repeatable trigger.
Understanding the Weakness (CWE)
Integrity,Confidentiality,Availability
Technical Impact: Modify Memory; Execute Unauthorized Code or Commands
When a program calls free() twice with the same argument, the program's memory management data structures may become corrupted, potentially leading to the reading or modification of unexpected memory addresses. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack. Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
