GHSA-9X4H-8WGM-8XFG

Malformed CAR panics and excessive memory usage

Versions impacted

• <= [email protected]
• <= [email protected]

Description

Decoding CAR data from untrusted user input can cause:

• Panics:
  • Out of bound memory access
  • Out of memory
  • Divide by zero
• Excessive memory usage

Such panics can be triggered by intentionally malformed CARv1 data, including CARv1 data within a CARv2 container; and also CARv2 data with excessively large indexes.

These vulnerabilities are not known to be exploited in the wild and were discovered primarily with the use of code fuzzing tooling.

Details

Out of bound memory access (OOB), out of memory (OOM) panics or excessive memory usage can be triggered by decode of malformed CARv1 headers, malformed CARv1 sections, and malformed CIDv0 data used in CARv1 sections. This also applies to CARv1 data within a CARv2 container.

Additionally, we wish to use this security advisory to make clear to consumers of CARv2 format data that loading CARv2 indexes from untrusted sources is dangerous and should be avoided. Where CAR data indexes are required, they should be regenerated locally. Out of memory (OOM) panics or excessive memory usage can be triggered by decode of intentionally malformed CARv2 indexes, or CARv2 indexes which are larger than available system memory (i.e. parallelization of CARv2 decodes may increase such a vulnerability).

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

Kodem intelligence

Already deployed Kodem?

Fixed versions

• >= [email protected]
• >= [email protected]

Description of user-facing changes

[email protected] imposes a fixed maximum header length and section length of 32 MiB during decode. Headers exceeding this length will cause the decoder to return an error as the initial CAR decode occurs. Sections (the combination of CID and block data) exceeding this length will cause the decoder to return an error as that section is read.

The default maximum of 32 MiB may be changed globally in an application instance by directly changing the MaxAllowedSectionSize variable in the github.com/ipld/go-car/util package.

We recommend that users of go-car@v0 upgrade to go-car@v2, where these maximums may be applied per-decode rather than globally.

[email protected] imposes a default maximum header length of 32 MiB and a default maximum section length of 8 MiB. Headers exceeding this length will cause the decoder to return an error as the initial CAR decode occurs. Sections (the combination of CID and block data) exceeding this length will cause the decoder to return an error as that section is read.

The default values may be adjusted by supplying a MaxAllowedHeaderSize(x) or MaxAllowedSectionSize(y) option to any decode function that accepts options. These include:

• OpenReader()
• NewReader()
• NewBlockReader()
• ReadVersion()
• LoadIndex()
• GenerateIndex()
• ReadOrGenerateIndex()
• WrapV1()
• ExtractV1File()
• ReplaceRootsInFile()
• blockstore/NewBlockReader()
• blockstore/NewReadOnly()
• blockstore/OpenReadOnly()
• blockstore/OpenReadWrite()

Please be aware that the default values are very generous and may be lowered where a user wants to impose restrictions closer to typical sizes.

• Typical header lengths should be in the order of 60 bytes, but the CAR format does not specify a maximum number of roots a header may contain. The default maximum of 32 MiB makes room for novel uses of the CAR format.
• Typical IPLD block sizes are under 2 MiB, and it is generally recommended that they not be above 1 MiB for maximum interoperability (e.g. there are hard limitations when sharing IPLD data with IPFS). CARv1 sections are the concatenation of CID and block bytes. The default maximum section length of 8 MiB makes room for novel IPLD data.

[email protected] introduces a new API that can be used to inspect a CAR and check for various errors, including those detailed in this advisory. The Reader#Inspect(bool) API returns a Stats object with various details about the CAR, such as its version, number of blocks, and details about codecs and multihashers used. When its argument is true, it will also perform a full hash consistency check of blocks contained within the CAR to ensure they match the CIDs. When false, block data is skipped over so a scan will likely be more efficient than reading blocks through a BlockReader if statistics and/or validity checking is all that's required. Note that Inspect() does minimal checking of index data; the strong recommendation is that if index data is untrusted then it should be regenerated.

[email protected] also includes additional documentation regarding the dangers of consuming CARv2 index data from untrusted sources and a recommendation to regenerate indexes of CAR data from such sources where an index is required.

1. What is GHSA-9X4H-8WGM-8XFG? GHSA-9X4H-8WGM-8XFG is a medium-severity uncontrolled resource consumption vulnerability in github.com/ipld/go-car (go), affecting versions < 0.4.0. It is fixed in 0.4.0, 2.4.0. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
2. Which packages are affected by GHSA-9X4H-8WGM-8XFG?
   • github.com/ipld/go-car (go) (versions < 0.4.0)
   • github.com/ipld/go-car/v2 (go) (versions >= 2.0.0, < 2.4.0)
3. Is there a fix for GHSA-9X4H-8WGM-8XFG? Yes. GHSA-9X4H-8WGM-8XFG is fixed in 0.4.0, 2.4.0. Upgrade to this version or later.
4. Is GHSA-9X4H-8WGM-8XFG exploitable, and should I be worried? Whether GHSA-9X4H-8WGM-8XFG is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-9X4H-8WGM-8XFG is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-9X4H-8WGM-8XFG?
   • Upgrade github.com/ipld/go-car to 0.4.0 or later
   • Upgrade github.com/ipld/go-car/v2 to 2.4.0 or later