CVE-2025-8225
BaseFortify
Publication date: 2025-07-27
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| gnu | binutils | 2.44 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-404 | The product does not release or incorrectly releases a resource before it is made available for re-use. |
| CWE-401 | The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-8225 is a memory leak vulnerability in GNU Binutils 2.44, specifically in the process_debug_info function of the DWARF Section Handler (binutils/dwarf.c). The issue occurs when the function incorrectly checks the variable num_debug_info_entries instead of alloc_num_debug_info_entries.parent to determine if memory has already been allocated for debug information. This leads to multiple allocations without proper deallocation, causing a memory leak when processing malformed or fuzzed DWARF debugging sections. [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can lead to a memory leak that causes gradual memory consumption and potential resource exhaustion on the affected system. Since the flaw occurs during local processing of crafted input files with malformed DWARF debugging sections, an attacker with local access can exploit it to degrade system availability or cause denial of service by exhausting memory resources. [2, 3]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by running the objdump utility from GNU Binutils 2.44 on crafted or fuzzed input files containing malformed DWARF debugging sections. Memory leak detection tools such as LeakSanitizer can be used to identify the memory leaks originating from the process_debug_info function. Specifically, running commands like `objdump --dwarf=info <crafted_input_file>` while monitoring with LeakSanitizer or similar memory analysis tools can reveal the leaks. The leaks manifest as repeated allocations without proper deallocation, with typical leak sizes of 128 bytes and 8192 bytes. [3]
What immediate steps should I take to mitigate this vulnerability?
The immediate step to mitigate this vulnerability is to apply the patch identified by commit e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4 available on the official GNU GitLab repository. This patch fixes the improper conditional check in the process_debug_info function, preventing the memory leak. Until the patch is applied, avoid processing untrusted or malformed DWARF debugging sections with objdump or other binutils tools to reduce the risk of exploitation. [1, 2, 3]