CVE-2023-31975: Yasm Memory Leak Vulnerability

CVE-2023-31975 Overview

A memory leak vulnerability was discovered in yasm v1.3.0, specifically in the yasm_intnum_copy function located at /libyasm/intnum.c. This vulnerability allows attackers to cause resource exhaustion through repeated invocations of the affected function, potentially leading to denial of service conditions in systems utilizing the yasm assembler.

Critical Impact

Memory leak in yasm assembler may lead to resource exhaustion and denial of service when processing specially crafted input files. Note that multiple third parties dispute this as a bug rather than a security vulnerability according to the YASM security policy.

Affected Products

• yasm v1.3.0

Discovery Timeline

• May 9, 2023 - CVE-2023-31975 published to NVD
• January 29, 2025 - Last updated in NVD database

Technical Details for CVE-2023-31975

Vulnerability Analysis

The vulnerability exists in the yasm_intnum_copy function within the yasm assembler's internal number handling library (libyasm/intnum.c). When this function is called to copy integer number structures, allocated memory is not properly released under certain conditions, resulting in a memory leak (CWE-401: Missing Release of Memory after Effective Lifetime).

The memory leak occurs during the copy operation of internal numeric representations, where dynamically allocated memory for the copied structure fails to be freed when the copied object is no longer needed. This can be triggered by processing assembly files that cause repeated invocations of the affected function.

It is important to note that this issue has been disputed by multiple third parties who argue it constitutes a bug rather than a security vulnerability, based on YASM's security policy and the practical exploitability of the issue.

Root Cause

The root cause is a classic CWE-401 vulnerability where the yasm_intnum_copy function allocates memory for copying internal numeric structures but does not ensure proper deallocation when the copied objects go out of scope or are no longer needed. This missing cleanup logic causes memory to accumulate over time during assembly operations that heavily utilize numeric copying operations.

Attack Vector

The attack vector requires local access and user interaction. An attacker would need to craft a malicious assembly source file designed to trigger repeated calls to the vulnerable yasm_intnum_copy function. When a user assembles this crafted file using yasm v1.3.0, memory consumption grows progressively without bound, potentially leading to:

• System slowdown due to excessive memory usage
• Denial of service through memory exhaustion
• Process termination when system memory limits are reached

The vulnerability mechanism involves allocating memory during the integer copy operation. The copied structure consumes memory that is never reclaimed, and repeated operations cause progressive memory exhaustion. See the GitHub Issue #210 for technical details.

Detection Methods for CVE-2023-31975

Indicators of Compromise

• Unusual memory growth in yasm processes during assembly operations
• System memory exhaustion when processing assembly files
• Abnormally large memory footprint for yasm compared to baseline operations

Detection Strategies

• Monitor memory usage of yasm processes using tools like valgrind or AddressSanitizer to detect leak patterns
• Implement resource monitoring to detect gradual memory consumption increases during build processes
• Review assembly source files for unusually complex or repetitive numeric operations that could trigger excessive copying

Monitoring Recommendations

• Set up memory usage alerts for build systems utilizing yasm
• Use memory profiling tools during development to identify leak patterns
• Monitor system resource utilization during automated build processes

How to Mitigate CVE-2023-31975

Immediate Actions Required

• Evaluate whether yasm v1.3.0 is used in your build environment and assess the risk based on your usage patterns
• Consider using alternative assemblers if memory-sensitive operations are critical to your workflow
• Implement resource limits on build processes to prevent complete system exhaustion

Patch Information

As of the last NVD update on January 29, 2025, no official vendor patch has been released for this issue. The YASM project has acknowledged the issue in GitHub Issue #210. Users should monitor the YASM project for updates and consider the multiple Openwall OSS-Security discussions that provide context on whether this constitutes a security vulnerability.

Workarounds

• Implement memory resource limits using ulimit or cgroups to constrain yasm process memory usage
• Consider using alternative assemblers such as NASM for memory-critical build environments
• Run yasm processes in isolated containers with defined memory limits to prevent system-wide impact

# Configuration example
# Set memory limits for yasm processes using ulimit
ulimit -v 1048576  # Limit virtual memory to 1GB

# Or use cgroups to limit memory for build processes
# Create a cgroup with memory limit
sudo cgcreate -g memory:/yasm_limit
sudo cgset -r memory.limit_in_bytes=1G yasm_limit

# Run yasm within the limited cgroup
sudo cgexec -g memory:yasm_limit yasm input.asm -o output.o