cli/context/store: limit decompressed size of TLS files on zip import

[UditDewan]

- What I did

Fixed a memory exhaustion issue in docker context import with zip archives (fixes #6917).

The meta.json entry of an imported zip archive is read through limitedReader (10MB cap), but tls/ entries were read with a bare io.ReadAll. Only the compressed archive size was capped, so a small crafted zip containing a highly compressible TLS entry could decompress to gigabytes and OOM the CLI.

- How I did it

• Read TLS entries in importZip through the same limitedReader already used for meta.json.
• Removed the l.N == 0 early-EOF branch from limitedReader.Read. Without this, content exceeding the limit was silently truncated (instead of rejected) whenever a read landed exactly on the remaining budget — which is deterministic for zip imports, since flate delivers 32KiB chunks that divide the 10MB cap evenly. True end-of-data still returns a clean io.EOF via the underlying reader.

- How to verify it

go test ./cli/context/store/

New regression tests:

• TestImportZipTLSDataTooLarge — imports a zip whose TLS entry inflates past the cap while the archive itself stays well under it, and asserts the import errors.
• an added TestLimitReaderReadAll case using iotest.OneByteReader that lands a read exactly on the limit with data remaining, and asserts the limit error is returned.

- Human readable description for the release notes

Fix `docker context import` allocating unbounded memory for TLS files contained in zip archives

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

This PR hardens docker context import (zip) against decompression-based memory exhaustion by enforcing size limits on decompressed TLS material and tightening limitedReader behavior.

Changes:

• Apply limitedReader when reading tls/ zip entries to cap decompressed TLS file size.
• Adjust limitedReader.Read semantics to avoid silently truncating when reads land exactly on the limit.
• Add regression tests covering oversized TLS zip entries and a boundary read case for limitedReader.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
cli/context/store/store.go	Caps decompressed reads for tls/ zip entries (and highlights loop-close/memory considerations).
cli/context/store/store_test.go	Adds a regression test for oversized decompressed TLS zip entries.
cli/context/store/io_utils.go	Updates limitedReader.Read to avoid truncation-at-limit behavior.
cli/context/store/io_utils_test.go	Extends tests to cover an exact-limit boundary case using iotest.OneByteReader.

Comments suppressed due to low confidence (2)

cli/context/store/store.go:485

• defer f.Close() inside the zip entry loop can accumulate many deferred closes when importing archives with lots of files, potentially exhausting file descriptors. Close the entry reader immediately after io.ReadAll instead of deferring.

			data, err := io.ReadAll(&limitedReader{R: f, N: maxAllowedFileSizeToImport})
			defer f.Close()
			if err != nil {
				return err
			}

cli/context/store/store.go:487

• This change caps each TLS entry’s decompressed size, but importZip still accumulates all TLS file contents in memory (tlsData.Endpoints[...].Files[...] = data) with no overall decompressed-size budget. A crafted zip with many highly-compressible TLS entries could still OOM the process even though each individual entry stays under the per-file limit.

			data, err := io.ReadAll(&limitedReader{R: f, N: maxAllowedFileSizeToImport})
			defer f.Close()
			if err != nil {
				return err
			}
			err = importEndpointTLS(&tlsData, zf.Name, data)
			if err != nil {

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.