CVE-2026-56289 in patch
Summary
by MITRE • 07/09/2026
GNU patch is vulnerable to a denial of service (DoS) due to improper validation of hunk (single block of changes in diff) line offsets in unified-diff input. A specially crafted patch can specify an extremely large line number, causing the application to enter an effectively infinite processing loop while attempting to locate the requested position. This results in excessive CPU consumption and prevents the process from completing. An attacker can trigger this behavior by supplying a malicious patch file, causing the utility to become unresponsive and require manual termination.
This issue has been fixed in the commit faba04ef4f2b410257f76c1b9dc85e350929c4b9
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/09/2026
The vulnerability in GNU patch represents a critical denial of service weakness that stems from inadequate input validation mechanisms within the unified diff parsing functionality. This flaw manifests when the application processes specially crafted patch files containing malformed hunk line offsets that specify extremely large numerical values. The root cause lies in the absence of proper bounds checking and validation procedures that should occur during the parsing phase of unified diff format inputs, allowing maliciously constructed offsets to bypass normal processing constraints.
The technical implementation of this vulnerability exploits the fundamental parsing logic that attempts to locate specific line positions within the target file based on the offset values provided in the patch hunks. When an attacker supplies a patch with an impossibly large line number, the patch utility enters a computationally intensive loop attempting to traverse the file structure to reach the specified position. This process becomes effectively infinite as the application continuously attempts to locate and validate positions that may exceed memory boundaries or computational limits, resulting in sustained high CPU utilization and complete system unresponsiveness.
From an operational perspective, this vulnerability poses significant risks to automated build systems, continuous integration pipelines, and any environment where GNU patch is used to apply code modifications. The resource exhaustion effect means that legitimate patch operations cannot proceed while the utility remains stuck in the infinite processing loop, potentially causing cascading failures in development workflows and deployment processes. The attack vector requires only the submission of a malicious patch file, making it particularly dangerous as it can be triggered through automated means without requiring privileged access or complex exploitation techniques.
Security standards such as CWE-129 and CWE-131 categorize this vulnerability under improper input validation and insufficient boundary checking respectively, while ATT&CK framework mappings align with T1499.1 for network denial of service attacks and T1059.007 for command and scripting interpreter usage patterns that could be employed to trigger the vulnerability in automated systems. The fix implemented in commit faba04ef4f2b410257f76c1b9dc85e350929c4b9 addresses this by introducing comprehensive bounds checking mechanisms that validate hunk offset values against reasonable limits before initiating any file traversal operations, ensuring that the patch utility can gracefully reject malicious inputs rather than consuming excessive computational resources.
The remediation approach demonstrates proper defensive programming practices that align with secure coding guidelines, establishing clear boundaries for acceptable input ranges and implementing early termination conditions for invalid parameters. This fix prevents the infinite loop condition by validating the mathematical feasibility of the specified line offsets before attempting any file manipulation operations, thereby maintaining system availability while preserving legitimate patch application functionality. Organizations should prioritize updating to patched versions of GNU patch to eliminate this risk, particularly in environments where patch files originate from untrusted sources or are automatically applied as part of deployment workflows.