GHSA-JC7W-C686-C4V9

Vulnerability from github – Published: 2025-08-28 19:36 – Updated: 2025-08-29 20:25
VLAI
Summary
github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives
Details

Summary

It is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn't include a magic number or has a checksum to detect such an issue according to the specification.

Note that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done.

Mitigations

The release v0.5.15 includes following mitigations:

  • The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size.
  • The default is 2 Gigabytes - 1 byte (2^31-1 bytes).
  • Users can check with the [Reader.Header] method what the actual values are in their LZMA files and set a smaller limit using ReaderConfig.
  • The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary.
  • The code supports stream sizes only up to a pebibyte (1024^5).

Note that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15.

Methods affected

Only software that uses lzma.NewReader or lzma.ReaderConfig.NewReader is affected. There is no issue for software using the xz functionality.

I thank @GregoryBuligin for his report, which is provided below.

Summary

When unpacking a large number of LZMA archives, even in a single goroutine, if the first byte of the archive file is 0 (a zero byte added to the beginning), an error writeMatch: distance out of range occurs. Memory consumption spikes sharply, and the GC clearly cannot handle this situation.

Details

Judging by the error writeMatch: distance out of range, the problems occur in the code around this function. https://github.com/ulikunitz/xz/blob/c8314b8f21e9c5e25b52da07544cac14db277e89/lzma/decoderdict.go#L81

PoC

Run a function similar to this one in 1 or several goroutines on a multitude of LZMA archives that have a 0 (a zero byte) added to the beginning.

const ProjectLocalPath = "some/path"
const TmpDir = "tmp"

func UnpackLZMA(lzmaFile string) error {
    file, err := os.Open(lzmaFile)
    if err != nil {
        return err
    }
    defer file.Close()

    reader, err := lzma.NewReader(bufio.NewReader(file))
    if err != nil {
        return err
    }

    tmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix)
    if err != nil {
        return err
    }
    defer func() {
        tmpFile.Close()
        _ = os.Remove(tmpFile.Name())
    }()

    sha256Hasher := sha256.New()
    multiWriter := io.MultiWriter(tmpFile, sha256Hasher)

    if _, err = io.Copy(multiWriter, reader); err != nil {
        return err
    }

    unpackHash := hex.EncodeToString(sha256Hasher.Sum(nil))
    unpackDir := filepath.Join(
        ProjectLocalPath, unpackHash[:2],
    )
    _ = os.MkdirAll(unpackDir, DirPerm)

    unpackPath := filepath.Join(unpackDir, unpackHash)

    return os.Rename(tmpFile.Name(), unpackPath)
}

Impact

Servers with a small amount of RAM that download and unpack a large number of unverified LZMA archives

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.13"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ulikunitz/xz"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-58058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-28T19:36:22Z",
    "nvd_published_at": "2025-08-28T22:15:32Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nIt is possible to put data in front of an LZMA-encoded byte stream without detecting the situation while reading the header. This can lead to increased memory consumption because the current implementation allocates the full decoding buffer directly after reading the header. The LZMA header doesn\u0027t include a magic number or has  a checksum to detect such an issue according to the [specification](https://github.com/jljusten/LZMA-SDK/blob/master/DOC/lzma-specification.txt).\n\nNote that the code recognizes the issue later while reading the stream, but at this time the memory allocation has already been done.\n\n### Mitigations\n\nThe release v0.5.15 includes following mitigations:\n\n- The ReaderConfig DictCap field is now interpreted as a limit for the dictionary size.\n- The default is 2 Gigabytes - 1 byte (2^31-1 bytes).\n- Users can check with the [Reader.Header] method what the actual values are in  their LZMA files and set a smaller limit using ReaderConfig.\n- The dictionary size will not exceed the larger of the file size and the minimum dictionary size. This is another measure to prevent huge memory allocations for the dictionary.\n- The code supports stream sizes only up to a pebibyte (1024^5).\n\nNote that the original v0.5.14 version had a compiler error for 32 bit platforms, which has been fixed by v0.5.15.\n\n### Methods affected\n\nOnly software that uses [lzma.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#NewReader) or [lzma.ReaderConfig.NewReader](https://pkg.go.dev/github.com/ulikunitz/xz/lzma#ReaderConfig.NewReader) is affected. There is no issue for software using the xz functionality.\n\nI thank  @GregoryBuligin for his report, which is provided below.\n\n### Summary\nWhen unpacking a large number of LZMA archives, even in a single goroutine, if the first byte of the archive file is 0 (a zero byte added to the beginning), an error __writeMatch: distance out of range__ occurs. Memory consumption spikes sharply, and the GC clearly cannot handle this situation.\n\n### Details\nJudging by the error  __writeMatch: distance out of range__, the problems occur in the code around this function.\nhttps://github.com/ulikunitz/xz/blob/c8314b8f21e9c5e25b52da07544cac14db277e89/lzma/decoderdict.go#L81\n\n### PoC\nRun a function similar to this one in 1 or several goroutines on a multitude of LZMA archives that have a 0 (a zero byte) added to the beginning.\n```\nconst ProjectLocalPath = \"some/path\"\nconst TmpDir = \"tmp\"\n\nfunc UnpackLZMA(lzmaFile string) error {\n\tfile, err := os.Open(lzmaFile)\n\tif err != nil {\n\t\treturn err\n\t}\n\tdefer file.Close()\n\n\treader, err := lzma.NewReader(bufio.NewReader(file))\n\tif err != nil {\n\t\treturn err\n\t}\n\n\ttmpFile, err := os.CreateTemp(TmpDir, TmpLZMAPrefix)\n\tif err != nil {\n\t\treturn err\n\t}\n\tdefer func() {\n\t\ttmpFile.Close()\n\t\t_ = os.Remove(tmpFile.Name())\n\t}()\n\n\tsha256Hasher := sha256.New()\n\tmultiWriter := io.MultiWriter(tmpFile, sha256Hasher)\n\n\tif _, err = io.Copy(multiWriter, reader); err != nil {\n\t\treturn err\n\t}\n\n\tunpackHash := hex.EncodeToString(sha256Hasher.Sum(nil))\n\tunpackDir := filepath.Join(\n\t\tProjectLocalPath, unpackHash[:2],\n\t)\n\t_ = os.MkdirAll(unpackDir, DirPerm)\n\n\tunpackPath := filepath.Join(unpackDir, unpackHash)\n\n\treturn os.Rename(tmpFile.Name(), unpackPath)\n}\n```\n\n\n\n### Impact\nServers with a small amount of RAM that download and unpack a large number of unverified LZMA archives",
  "id": "GHSA-jc7w-c686-c4v9",
  "modified": "2025-08-29T20:25:38Z",
  "published": "2025-08-28T19:36:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ulikunitz/xz/security/advisories/GHSA-jc7w-c686-c4v9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58058"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ulikunitz/xz/commit/88ddf1d0d98d688db65de034f48960b2760d2ae2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ulikunitz/xz"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "github.com/ulikunitz/xz leaks memory when decoding a corrupted multiple LZMA archives"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.