Skip to content

fix: acquire read lock for r.blobs in test registry POST handler #678

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ilopezluna merged 1 commit into from
Feb 16, 2026
+2 −0
Merged

fix: acquire read lock for r.blobs in test registry POST handler #678

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions pkg/distribution/registry/testregistry/registry.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,9 @@ func (r *Registry) handleBlobUpload(w http.ResponseWriter, req *http.Request, pa
switch req.Method {
case http.MethodPost:
// Start upload
r.mu.RLock()
uploadID := fmt.Sprintf("upload-%d", len(r.blobs))
r.mu.RUnlock()
Comment on lines +72 to +74
Copy link
Contributor

@sourcery-ai sourcery-ai bot Feb 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): Using RLock here still allows concurrent readers to generate duplicate upload IDs based on len(r.blobs).

Because RLock allows concurrent readers, multiple goroutines can observe the same len(r.blobs) and generate identical uploadIDs. To ensure uniqueness, this section should either use the exclusive mutex (mu.Lock/mu.Unlock) around ID generation, or switch to a different mechanism (e.g., atomic counter or UUID). As is, the map access is safe but the ID generation still has a race condition.

Comment on lines +72 to +74
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

While the RLock correctly prevents a data race when reading len(r.blobs), using len(r.blobs) to generate the uploadID can still lead to non-unique identifiers in a concurrent environment. Multiple concurrent requests could read the same len(r.blobs) value, resulting in identical uploadIDs. This could cause issues if clients expect unique Docker-Upload-UUIDs or if the Location header is used for subsequent operations that rely on a unique identifier. Consider using a universally unique identifier (UUID) generator (e.g., github.com/google/uuid) or an atomic counter to ensure that uploadIDs are unique across concurrent requests. This would provide a more robust and standard way to generate upload identifiers.

location := fmt.Sprintf("/v2/%s/blobs/uploads/%s", repo, uploadID)
w.Header().Set("Location", location)
w.Header().Set("Docker-Upload-UUID", uploadID)
Expand Down