CVE-2025-67269: gpsd Integer Underflow DoS Vulnerability

CVE-2025-67269 Overview

An integer underflow vulnerability exists in the nextstate() function in gpsd/packet.c of gpsd versions prior to commit ffa1d6f40bca0b035fc7f5e563160ebb67199da7. When parsing a NAVCOM packet, the payload length is calculated using lexer->length = (size_t)c - 4 without checking if the input byte c is less than 4. This results in an unsigned integer underflow, setting lexer->length to a very large value (near SIZE_MAX). The parser then enters a loop attempting to consume this massive number of bytes, causing 100% CPU utilization and a Denial of Service (DoS) condition.

Critical Impact

Remote attackers can exploit this integer underflow to cause complete CPU exhaustion and denial of service by sending specially crafted NAVCOM packets to gpsd services.

Affected Products

• gpsd versions prior to commit ffa1d6f40bca0b035fc7f5e563160ebb67199da7

Discovery Timeline

• 2026-01-02 - CVE CVE-2025-67269 published to NVD
• 2026-01-06 - Last updated in NVD database

Technical Details for CVE-2025-67269

Vulnerability Analysis

This vulnerability is classified as CWE-191 (Integer Underflow), which occurs when an arithmetic operation attempts to create a numeric value that is smaller than the minimum value the data type can represent. In the case of unsigned integers, this causes the value to wrap around to a very large number.

The vulnerable code path exists within the NAVCOM packet parsing logic of gpsd's packet state machine. The nextstate() function processes incoming bytes and calculates payload lengths for various GPS protocol packets. When handling NAVCOM protocol data, the code subtracts 4 from the input byte value without first validating that the byte is greater than or equal to 4.

Since lexer->length is of type size_t (an unsigned integer type), subtracting 4 from a value less than 4 causes an integer underflow. For example, if the input byte c has a value of 0, the calculation (size_t)0 - 4 wraps around to approximately 18,446,744,073,709,551,612 on 64-bit systems (or 4,294,967,292 on 32-bit systems).

The consequence of this massive length value is that the parser enters a state expecting to receive an enormous number of bytes before completing packet processing. This creates an infinite-like loop condition that consumes 100% CPU resources, effectively causing a denial of service.

Root Cause

The root cause is a missing bounds check before performing arithmetic on user-controlled input. The vulnerable code performs the subtraction lexer->length = (size_t)c - 4 without validating that the byte value c is at least 4. This violates secure coding practices for unsigned integer arithmetic, where input validation must occur before any subtraction operations that could result in underflow.

Attack Vector

An attacker can exploit this vulnerability remotely over the network by sending a malformed NAVCOM packet to a gpsd service. The attack requires crafting a packet where the length byte field contains a value less than 4. When gpsd receives and parses this packet, the integer underflow triggers, causing the parsing loop to attempt processing of an impossibly large number of bytes.

The attack is particularly concerning because:

1. It requires no authentication to exploit
2. It can be triggered with a single malformed packet
3. The resulting CPU exhaustion persists until the gpsd process is terminated
4. Systems relying on GPS data (navigation, timing synchronization, fleet management) lose functionality

Proof-of-concept details are available at the GitHub CVE-2025-67269 PoC repository.

Detection Methods for CVE-2025-67269

Indicators of Compromise

• Abnormal CPU utilization (100%) by gpsd process
• gpsd service becoming unresponsive to legitimate GPS data requests
• System logs showing gpsd packet parsing anomalies or timeouts
• Network traffic containing malformed NAVCOM packets with length bytes less than 4

Detection Strategies

• Monitor gpsd process CPU usage and alert on sustained high utilization exceeding normal operational thresholds
• Implement network-level inspection for malformed NAVCOM protocol packets targeting gpsd services
• Deploy application-level monitoring to detect gpsd service unresponsiveness or timeout conditions
• Use SentinelOne's behavioral AI detection to identify processes exhibiting denial-of-service patterns such as infinite loops

Monitoring Recommendations

• Configure resource monitoring alerts for gpsd processes with CPU thresholds appropriate to your environment
• Implement network flow analysis to detect anomalous traffic patterns to gpsd service ports
• Enable detailed logging for gpsd services to capture packet parsing errors and anomalies
• Review system health metrics regularly for signs of resource exhaustion attacks

How to Mitigate CVE-2025-67269

Immediate Actions Required

• Update gpsd to the patched version containing commit ffa1d6f40bca0b035fc7f5e563160ebb67199da7 or later
• Implement network segmentation to limit access to gpsd services from untrusted networks
• Configure firewall rules to restrict gpsd service access to known and trusted GPS data sources only
• Consider running gpsd with resource limits (cgroups, ulimit) to prevent complete system exhaustion

Patch Information

The vulnerability has been addressed in the GPSD GitLab repository through commit ffa1d6f40bca0b035fc7f5e563160ebb67199da7. This commit adds proper bounds checking to validate that the input byte value is at least 4 before performing the subtraction operation.

Organizations should update to the latest gpsd release that includes this fix. The specific patch can be reviewed at the GitLab commit page.

Workarounds

• Restrict network access to gpsd services using firewall rules to allow connections only from trusted GPS devices and internal systems
• Deploy gpsd behind a reverse proxy or application gateway that can filter malformed packets
• Run gpsd in a containerized environment with strict resource limits to contain the impact of exploitation
• Monitor and automatically restart gpsd processes that exhibit abnormal CPU consumption patterns

# Example: Restrict gpsd access using iptables
# Allow only trusted GPS device IP
iptables -A INPUT -p tcp --dport 2947 -s 192.168.1.100 -j ACCEPT
iptables -A INPUT -p tcp --dport 2947 -j DROP

# Example: Run gpsd with CPU resource limits using systemd
# Add to gpsd.service [Service] section:
# CPUQuota=50%
# MemoryLimit=256M