Resolves https://github.com/fleetdm/confidential/issues/16902
- [x] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
## Testing
- [x] Added/updated automated tests
- [x] QA'd all new/changed functionality manually
## Reproduction
**Attack vector:** An authenticated Fleet admin uploads a crafted `.msi`
file via the software upload API. The server's MSI metadata parser
(`pkg/file/msi.go` > `ExtractMSIMetadata` > `decodeStrings`) processes
the file's `_StringPool` and `_StringData` streams during upload. A
malicious `_StringPool` can claim arbitrarily large string sizes that
trigger speculative memory allocation before the actual data is read.
**Manual reproduction:** Wrote a standalone Go program that constructs
the two raw byte streams the parser consumes (a 12-byte `_StringPool`
claiming a 64 MB string, and an empty 0-byte `_StringData`), then
measures heap allocation via `runtime.MemStats` before and after calling
the vulnerable code path.
**Before fix (vulnerable):**
```
Pool input size: 12 bytes
StringData size: 0 bytes
Claimed string size: 67108864 bytes (64 MB)
Error returned: failed to read string data: EOF
Heap allocated: 67117016 bytes (64.0 MB)
Amplification: 12 input bytes -> 67117016 byte allocation (5593084x)
```
12 bytes of pool input forced a 64 MB heap allocation via `buf.Grow()`
before `io.CopyN` discovered there was no data to read.
**After fix:**
```
Error returned: failed to read string data: EOF
Heap allocated: 3072 bytes (3.0 KB)
Memory amplification eliminated: true
```
Same input, 3 KB allocated instead of 64 MB. Without the speculative
`buf.Grow()`, `io.CopyN` grows the buffer incrementally based on actual
available data and immediately hits EOF.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Fixed a potential resource exhaustion issue when processing MSI
metadata with unusually large string-size declarations.
- MSI files with missing string data are now handled without excessive
memory allocation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Lucas Manuel Rodriguez <lucas@fleetdm.com>
