embeddedfs/qcow2: cap header extension length to prevent OOM

[adilburaksen]

Summary

parseHeader in extractor/filesystem/embeddedfs/qcow2/format.go reads
QCOW2 header extensions in a loop and allocates make([]byte, ext.Length)
before calling io.ReadFull. ext.Length is a uint32 field read directly
from the (untrusted) file — no bounds check exists.

Impact: A crafted 120-byte QCOW2 file with ext.Length = 0xffffffff
causes a ~4 GB heap allocation at parse time, well before io.ReadFull
returns EOF. Confirmed live:

TotalAlloc delta: 4096 MB   (120-byte input)

All other parseHeader guards (ClusterBits, L1Size,
RefcountTableClusters) pass cleanly on the malicious file.

Fix

Add const maxExtensionLength = 64 << 10 (64 KB) guard immediately before
make([]byte, ext.Length). Real QCOW2 extensions (feature-name strings,
backing-file format strings) are always a few dozen bytes; 64 KB is generous.

Test

TestConvertQCOW2ExtLengthRejected in security_regression_test.go:

• Constructs the 120-byte bomb file at test time (no binary testdata needed).
• Confirms convertQCOW2ToRaw returns a non-nil error.
• Asserts TotalAlloc delta stays below 50 MB.

After fix: TotalAlloc delta: 0 MB ✓

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[adilburaksen]

/gcbcla check

[adilburaksen]

Hi! Just a friendly ping — all CI checks are passing. Happy to address any review feedback whenever you get a chance. Thanks for your time!