Duplicate Part Numbers in CompleteMultipartUpload

Mon, 03 Aug 2026 00:00:00 +0000

In CompleteMultipartUpload, the S3 API requires part numbers in the completion XML to be strictly ascending. Up through Server 20260725, SILO enforced that invariant with sort.SliceIsSorted and a strict < comparator—which accepts non-decreasing sequences such as [1, 1] and duplicates the referenced part in the assembled object. Server 20260804 (pgsty/silo#49) replaces that check with an explicit adjacent-pair comparison (Parts[i-1].PartNumber >= Parts[i].PartNumber) and fixes an adjacent empty-part panic in ReadParts (2602177ef).

Conclusions first

The bug is real and small: CompleteMultipartUpload used sort.SliceIsSorted with <, which tests non-decreasing order (a[0] <= a[1] <= ...) rather than strictly increasing order (a[0] < a[1] < ...). Passing duplicate part numbers such as [1, 1] succeeded and duplicated the underlying part in the final object.
This is a data-integrity defect, not a CVE: Triggering it requires a caller who already holds s3:PutObject permission on the target key and a valid uploadId for an in-progress multipart upload. It does not cross tenant, bucket, or credential boundaries.
The fix stays at the HTTP handler boundary: cmd/object-handlers.go rejects Parts[i-1].PartNumber >= Parts[i].PartNumber with InvalidPartOrder (HTTP 400). Sparse part numbers ([1, 3], [5, 9], [3]) remain valid.

Why `sort.SliceIsSorted` Accepted Duplicates

In cmd/object-handlers.go, CompleteMultipartUploadHandler validated the parsed <CompleteMultipartUpload> part list with:

Correctness on SILO

Duplicate Part Numbers in CompleteMultipartUpload

Conclusions first

Why sort.SliceIsSorted Accepted Duplicates

Why `sort.SliceIsSorted` Accepted Duplicates