stat.go: /proc/stat processes field overflow causes parseStat() to fail entirely

[jsczrangel]

Bug Report: /proc/stat processes field overflow causes entire Stat() parsing to fail

Affected Code

stat.go — parseStat() function, processes case (lines ~177-180):

case parts[0] == "processes":
    if stat.ProcessCreated, err = strconv.ParseUint(parts[1], 10, 64); err != nil {
        return Stat{}, fmt.Errorf("%w: couldn't parse %q (processes): %w", ErrFileParse, parts[1], err)
    }

Root Cause

The processes field in /proc/stat represents "number of forks since boot" and is stored as an unsigned int in the Linux kernel. On long-running systems (300+ days) with high process churn, this counter wraps around and /proc/stat reports a negative integer string:

processes -1948031333

strconv.ParseUint cannot parse negative values, causing the entire parseStat() function to return an error. This breaks ALL consumers that depend on Stat(), including:

• node_exporter CPU collector — zero CPU metrics exposed
• node_exporter stat collector — zero stat metrics exposed

Impact

This affects any system with >4 billion process forks since boot. In containerized environments (Kubernetes), containers start and stop frequently, accelerating the counter overflow.

Reproduction

# On a system with uptime >300 days:
cat /proc/stat | grep "^processes"
# processes -1948031333  ← negative!

# Any code calling fs.Stat() fails:
# "couldn't parse \"-1948031333\" (processes): strconv.ParseUint: parsing \"-1948031333\": invalid syntax"

Tested and confirmed failing on:

• node_exporter v1.3.1 through v1.8.2 (all versions)
• procfs v0.21.0 (latest as of June 2026)
• Linux kernel 5.x, system uptime 388 days

Proposed Fix

Use strconv.ParseInt instead of strconv.ParseUint for the processes field. In Go, converting a negative int64 to uint64 produces the correct unsigned representation via two's complement:

case parts[0] == "processes":
    v, err := strconv.ParseInt(parts[1], 10, 64)
    if err != nil {
        // Don't fail the entire Stat() — skip this field gracefully
        break
    }
    stat.ProcessCreated = uint64(v)

This handles both cases:

• Normal: ParseInt("12345") → int64(12345) → uint64(12345) ✓
• Overflowed: ParseInt("-1948031333") → int64(-1948031333) → correct uint64 ✓

References

• node_exporter issue: cpu collector/stat collector,couldn't parse -2049562273 (processes) node_exporter#1882
• Linux kernel /proc/stat implementation: https://gitlab.com/linux-kernel/stable/-/blob/master/fs/proc/stat.c

Environment

Component	Version
procfs	master (v0.21.0)
node_exporter	v1.3.1 / v1.8.2
Linux kernel	5.x
System uptime	388 days
/proc/stat processes	-1948031333

[SuperQ]

Can you provide more evidence as to what exactly kernel versions are causing this?

[happysnaker]

Follow-up for the kernel-version question:

There is at least one earlier public reproduction in prometheus/node_exporter#1882 on Linux centos 4.14.105-19-0016 x86_64, where /proc/stat was reported as:

processes -2045677862

That thread also includes the full /proc/stat dump from the affected host. The newer report here mentions Linux 5.x with a 388-day uptime, but the older node_exporter issue at least gives us one concrete kernel string plus an observed negative processes line on a real system.

So I do not think this patch needs to claim a complete list of affected kernels. The narrower point is: procfs already sees this invalid-but-real input in the field, and today it hard-fails the whole parse. PR #836 just makes the parser tolerant of the observed wrapped negative form while keeping the existing unsigned fast path for normal systems.

[SuperQ]

The problem is if the value is negative I don't think we can safely do anything with it. Without some harder evidence that just pretending the wrap is valid I don't think we can accept this.

As it has been stated before, the kernel print formatting and data type is pretty clearly unsigned long.