Various memory access violations in 7-Zip

[Alan Coopersmith <alan.coopersmith () oracle com>]

GitHub's Security Lab has published two advisories about memory access
violations in 7-Zip, which were fixed in 7-Zip 26.01.

I've omittted code analysis & proof-of-concept code chunks in the below,
see the provided URL's to view those with much better formatting than
plain-text email allows.

https://securitylab.github.com/advisories/GHSL-2026-115_GHSL-2026-122_7-zip/
says:
> May 22, 2026
> GHSL-2026-115–GHSL-2026-122: Various memory access violations in 7-Zip
>
> Author: Jaroslav Lobačevski
>
> Coordinated Disclosure Timeline
>
>     2026-04-21: The report was delivered through sourceforge private issues.
>     2026-04-27: v26.01 with fixes was released.
>
> Summary
> -------
> The 7-Zip project, version 26.00, contains various memory access violations,
> out-of-bounds (OOB) read issues, uninitialized memory vulnerabilities, integer
> overflow flaws in various archive formats (e.g., 7z, SquashFS, UDF, UEFI, WIM,
> and Ar), and path traversal in sample app, which could potentially lead to
> compromising system integrity or accessing sensitive data.
>
> Project: 7-Zip
> Tested Version: v26.00
>
> Issue 1: SquashFS Fragment Offset Overflow (GHSL-2026-116)
> ==========================================================
>
> Heap memory disclosure via SquashFS fragment offset integer overflow on 32-bit
> builds.
>
> 32-bit integer overflow in the SquashFS ReadBlock function allows an
> attacker-controlled node.Offset value to bypass the fragment bounds
> check, causing memcpy to read heap memory preceding the cache buffer
> into the extracted file. The vulnerability is exploitable only on
> 32-bit builds of 7-Zip where size_t is 32 bits, allowing the addition
> offsetInBlock + blockSize to wrap modulo 2³². On 64-bit builds the
> addition is promoted to 64 bits and the check correctly rejects the
> input.
>
> [...]
>
> Impact
> ------
> This issue may lead to information disclosure (heap memory preceding
> _cachedBlock written into extracted file) on 32-bit builds.
>
>   - The SquashFS handler is registered for .squashfs and .sfs files and is
>     enabled in stock 7z.dll.
>   - 32-bit builds of 7-Zip are shipped on the official 7-zip.org downloads page.
>   - The vulnerability triggers during extraction — the attacker recovers heap
>     contents by reading the extracted file.
>   - The attacker controls the read offset via node.Offset and the read size
>     via FileSize (up to _h.BlockSize, max 8 MiB).
>   - Heap memory preceding _cachedBlock (up to BlockSize bytes) is written into
>     the extracted file — an in-band information disclosure primitive.
>   - On 64-bit builds, the bug is latent (bounds check is correct due to 64-bit
>     promotion).
>
> CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — 6.5 (Medium)
>
> Scored for 32-bit builds where the disclosure is real.
>
> Affected versions: The SquashFS fragment ReadBlock with offsetInBlock has been
> present since 7-Zip 9.18. All 32-bit builds from 9.18 through 26.00 are affected.
> 64-bit builds are not affected.
>
> CWEs
> -----
>     CWE-190: “Integer Overflow or Wraparound”
>     CWE-125: “Out-of-bounds Read”
>
>
> Issue 2: UEFI Capsule uninitialized heap memory disclosure (GHSL-2026-117)
> ==========================================================================
>
> Uninitialized heap memory disclosure in 7-Zip UEFI capsule handler via
> truncated archive.
>
> An uninitialized memory disclosure vulnerability exists in the UEFI
> capsule (.scap) parser in 7-Zip. The OpenCapsule function allocates a
> heap buffer of attacker-declared CapsuleImageSize (up to 1 GiB)
> without zero-initialization, then reads the file contents into it with
> ReadStream_FALSE whose return value is silently discarded. If the file
> is truncated, the unread tail of the buffer retains uninitialized heap
> memory, which is then exposed as extracted file content via GetStream.
>
> [...]
>
> Impact
> -------
> This issue may lead to information disclosure (uninitialized heap memory
> written to extracted files).
>
>   - The UEFI capsule handler is registered for .scap files with signature-based
>     detection (NArcInfoFlags::kFindSignature) and is enabled in stock 7z.dll.
>   - The vulnerability triggers on extraction (GetStream is called when the user
>     extracts a file from the archive).
>   - Usual operation — the user just opens and extracts a malicious .scap file.
>   - Up to ~1 GiB of uninitialized heap memory is written to disk as extracted
>     file content. In a long-running 7-Zip GUI session (warm heap), this can
>     include fragments of previously processed archives, file paths, decompressed
>     content, or passwords from encrypted archive sessions.
>   - On Windows, even a cold (freshly launched) process leaks non-zero heap
>     metadata. On Linux the cold leak contains zeros, the “warm” process leaks
>     the non-zero heap. The GUI is the primary concern because it is long-running.
>
> CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — 6.5 (Medium)
>
> Affected versions: The unchecked ReadStream_FALSE has been present since
> 7-Zip 9.21. All versions from 9.21 through 26.00 are affected.
>
> CWEs
> ----
>     CWE-908: “Use of Uninitialized Resource”
>
>
> Issue 3: UDF Field OOB Read (GHSL-2026-118)
> ===========================================
> Up-to-3-byte heap OOB read in UDF File Identifier padding loop.
>
> The UDF disc image parser’s CFileId::Parse function reads up to 3
> bytes past the end of the heap-allocated directory buffer in the
> alignment-padding scan loop. The bounds check processed <= size is
> performed after the OOB reads, not before.
>
> [...]
>
> Impact
> ------
> This issue may lead to information disclosure (1-bit oracle per OOB byte
> via open/fail behavior).
>
>   - The UDF handler is registered for .iso, .udf and auto-detected by signature.
>   - Triggers during Open() — listing or extracting a crafted UDF image.
>   - OOB read of up to 3 bytes per FID parse.
>
> CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N — 3.1 (Low)
>
> Affected versions: The UDF handler has been present since 7-Zip 9.11.
> All versions through 26.00 are affected.
>
> CWEs
> -----
>     CWE-125: “Out-of-bounds Read”
>
>
> Issue 4: WIM SecurityId OOB read (GHSL-2026-119)
> ================================================
> Off-by-one heap out-of-bounds read in 7-Zip WIM security descriptor handler.
>
> An off-by-one heap out-of-bounds read exists in the WIM (Windows Imaging)
> archive handler in 7-Zip. The CHandler::GetSecurity function validates a
> securityId against SecurOffsets.Size() but then accesses
> SecurOffsets[securityId + 1], reading 4 bytes past the end of the heap
> allocation when securityId equals the maximum allowed value. The OOB
> is triggered on viewing (double-click or File -> Open) a crafted WIM
> in the 7-Zip File Manager GUI.
>
> [...]
>
> Impact
> ------
> This issue may lead to limited information disclosure (OOB bytes used
> arithmetically but not surfaced to attacker).
>
>   - The WIM handler is registered for .wim, .swm, .esd, .ppkg files and is
>     enabled in stock 7z.dll.
>   - GetSecurity is called when any frontend queries kpidNtSecure via
>     IArchiveGetRawProps::GetRawProp.
>   - The file manager’s ListView calls GetRawProp(kpidNtSecure) for every item
>     during listing — the OOB triggers immediately upon opening the WIM, with
>     no extraction or user interaction.
>   - CLI: The console tool triggers the OOB when listing with technical info
>     (7zz l -slt).
>   - The attacker controls securityId via the SecurityId field at offset +0xC
>     of any directory entry in the WIM metadata.
>   - The OOB value is used arithmetically (len = OOB_value - offs) to compute
>     a metadata buffer slice length. If the garbage len fails the subsequent
>     bounds check, the function returns S_OK with no data.
>
> CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L — 3.5 (Low)
>
> Affected versions: The WIM security descriptor support (GetSecurity with
> SecurOffsets) was introduced in 7-Zip 9.34. The off-by-one has been present
> since introduction. All versions from 9.34 through 26.00 are affected.
>
> CWEs
> ----
>     CWE-125: “Out-of-bounds Read”
>
>
> Issue 5: SquashFS BlockToNode uninitialized heap read (GHSL-2026-120)
> =====================================================================
>
> Uninitialized heap read via sparse _blockToNode index in SquashFS handler.
>
> The SquashFS handler’s OpenDir function indexes the _blockToNode array
> using attacker-controlled blockIndex values. The array is allocated
> with ClearAndReserve(GetNumBlocks() + 1) but only partially populated
> during inode parsing — when few inodes span many metadata blocks, most
> slots remain uninitialized. Reading these uninitialized UInt32 values
> provides attacker-influenced bounds to FindInSorted, which then
> performs an unbounded heap read via _nodesPos[mid]. If the OOB-read
> value coincidentally matches unpackPos, the returned nodeIndex chains
> into a wild-pointer read of _nodes[nodeIndex] — though this
> amplification is heap-layout-dependent and not reliably triggerable.
>
> Impact
> ------
> This issue may lead to information disclosure (heap content leakage
> via chained OOB reads) and denial of service (crash from wild-pointer
> dereference). The SquashFS handler is enabled in stock 7z.dll and
> triggers during Open() before any user interaction beyond opening the
> file.
>
>   - The attacker controls RootInode in the superblock and the metadata
>     block layout.
>   - Uninitialized heap values feed into indexed reads, creating an
>     attacker-influenced OOB read chain.
>   - No write primitive.
>
> CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L — 4.2 (Medium)
>
> AC:H because exploiting the uninitialized values for controlled reads
> requires heap layout manipulation.
>
> Affected versions: The _blockToNode optimization has been present since
> 7-Zip 9.18. All versions through 26.00 are affected.
>
> CWEs
> ----
>     CWE-908: “Use of Uninitialized Resource”
>     CWE-125: “Out-of-bounds Read”
>
> Issue 6: UEFI DEPEX OOB Read (GHSL-2026-121)
> ============================================
>
> Off-by-one out-of-bounds read in 7-Zip UEFI dependency expression parser.
>
> An off-by-one out-of-bounds read exists in the UEFI firmware image
> parser in 7-Zip. The ParseDepedencyExpression function uses > instead
> of >= when validating an attacker-controlled opcode byte against the
> bounds of a static array of const char * pointers. When command == 10,
> the function reads one pointer past the end of the 10-element
> kExpressionCommands array, then dereferences that pointer as a C
> string, causing either a crash or a leak of adjacent .rodata content
> into archive metadata.
>
>
> Impact
> ------
> This issue may lead to denial of service (crash from dereferencing an invalid
> pointer) or minor information disclosure (adjacent .rdata string leaked into
> archive metadata).
>
>   - Static array OOB read: kExpressionCommands[10] reads 8 bytes (one pointer
>     slot) past the end of a 10-element static .rdata array. Because adjacent
>     .rdata is always readable (same PE section), this does not typically crash.
>     On the tested build, the adjacent bytes form a valid pointer to another
>     string literal, so strlen + memcpy succeed silently.
>   - No meaningful information disclosure: The content at the dereferenced OOB
>     pointer is a static string from the binary’s own .rdata — identical to what
>     anyone can extract with a hex editor. No user secrets, no heap data, no
>     ASLR base address is leaked.
>   - Linker-dependent crash: If a different build places non-pointer data
>     adjacent to kExpressionCommands, the strlen dereference would fault with
>     ACCESS_VIOLATION (DoS). This is linker-layout dependent, not deterministic
>     across builds.
>
> CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L — 3.5 (Low)
>
> Affected versions: The off-by-one has been present since 7-Zip 9.21, the first
> version to include the UEFI handler. All versions through 26.00 are affected.
>
> CWEs
> ----
>     CWE-125: “Out-of-bounds Read”
>
>
> Issue 7: Ar SYMDEF OOB Read (GHSL-2026-122)
> ===========================================
> Heap out-of-bounds read in 7-Zip Ar handler BSD SYMDEF parser.
>
> A 4-byte heap out-of-bounds read exists in the Unix ar archive parser
> in 7-Zip. When parsing a BSD-style __.SYMDEF symbol table, the
> ParseLibSymbols function reads a 32-bit namesSize field via Get32 at a
> position that can equal the buffer size, reading 4 bytes past the end
> of the heap allocation. This reads uninitialized heap data under the
> default allocator.
>
> Impact
> ------
> This issue may lead to limited information disclosure (OOB bytes used in
> bounds check but not surfaced to output).
>
>   - The Ar handler is registered for .a, .ar, .lib, and .deb file extensions.
>     The handler IS enabled in stock 7z.dll.
>   - ParseLibSymbols is called from Open at line 627, triggered whenever the
>     first or second archive member is named __.SYMDEF or __.SYMDEF SORTED.
>   - The vulnerability triggers during IInArchive::Open(), before any extraction.
>   - Limited information disclosure: The OOB bytes are stored in namesSize
>     (local variable) but are only used in the subsequent bounds check at line
>     478, which always fails (causing continue). The leaked bytes do not flow
>     into any output stream visible to the attacker.
>
> CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L — 3.5 (Low)
>
> Affected versions: The SYMDEF parsing was introduced in 7-Zip 9.34.
> The off-by-4 OOB has been present in all versions from 9.34 through 26.00.
>
> CWEs
> ----
>     CWE-125: “Out-of-bounds Read”
>
>
> Issue 8: Missing path validation in extraction loop (GHSL-2026-115)
> ===================================================================
> Path traversal in 7zDec SDK sample extractor allows arbitrary file write.
>
> The 7zDec standalone LZMA SDK sample extractor (C/Util/7z/7zMain.c) does not
> validate archive entry paths for directory traversal sequences (..), absolute
> paths, or other unsafe path components when extracting in x (full paths) mode.
> An attacker-controlled 7z archive can write files to arbitrary locations on
> the filesystem, enabling code execution via overwriting startup scripts, SSH
> keys, or system configuration files.
>
> Impact
> ------
> It is a sample extractor which may be used as example. This issue may lead to
> arbitrary file write and remote code execution (overwrite shell rc files, cron
> jobs, SSH keys). 7zDec is built from the LZMA SDK and is a working binary that
> users invoke on untrusted archives. The attack requires only delivering a
> crafted 7z archive — no special privileges, no race conditions.
>
> CWEs
> -----
>     CWE-22: “Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)”
>
>
> CVE
> ---
>     GHSL-2026-115: Sample app
>     GHSL-2026-116: CVE-2026-48092
>     GHSL-2026-117: CVE-2026-48101
>     GHSL-2026-118: CVE-2026-48102
>     GHSL-2026-119: CVE-2026-48103
>     GHSL-2026-120: CVE-2026-48104
>     GHSL-2026-121: CVE-2026-48111
>     GHSL-2026-122: CVE-2026-48112
>
> Credit
> ------
> These issues were discovered and reported by GHSL team member
> @JarLob (Jaroslav Lobačevski).
>
> Contact
> -------
> You can contact the GHSL team at securitylab () github com, please include a
> reference to GHSL-2026-115, GHSL-2026-116, GHSL-2026-117, GHSL-2026-118,
> GHSL-2026-119, GHSL-2026-120, GHSL-2026-121, or GHSL-2026-122 in any
> communication regarding these issues.

https://securitylab.github.com/advisories/GHSL-2026-140_7-Zip/ says:
> May 22, 2026
> GHSL-2026-140: Heap Buffer Write Overflow in 7-Zip
>
> Author: Jaroslav Lobačevski
>
> Coordinated Disclosure Timeline
>
>     2026-04-24: The report was delivered as a sourceforge private issue.
>     2026-04-27: v26.01 with a fix was released.
>
> Summary
> -------
> A heap buffer overflow vulnerability (GHSL-2026-140) exists in 7-Zip version
> 26.00, caused by an under-allocation in the NTFS compressed stream buffer
> (GetCuSize shift UB), potentially allowing attackers to exploit this issue
> for arbitrary code execution or application crashes.
>
> Project: 7-Zip
> Tested Version: v26.00
>
> Details
> -------
> Heap buffer overflow via NTFS compressed stream buffer under-allocation
> (GetCuSize shift UB) (GHSL-2026-140)
>
> A heap buffer overflow vulnerability exists in the NTFS archive
> handler in 7-Zip that can lead to code execution via vtable
> hijack. The CInStream::GetCuSize() function computes the NTFS
> compression-unit buffer size using a 32-bit shift (UInt32)1 <<
> (BlockSizeLog + CompressionUnit). When an attacker-crafted NTFS image
> sets ClusterSizeLog >= 28 (accepted by the parser) and a compressed
> data attribute with CompressionUnit == 4, the shift exponent reaches
> 32 — undefined behavior in C++. On both x86 and x64, the UB causes
> _inBuf to be allocated as 1 byte. The subsequent ReadStream_FALSE
> writes 256 MB of attacker-controlled data into this 1-byte buffer.
>
> [...]
>
> Impact
>
>     Heap buffer overflow leading to vtable hijack (potential code execution) —
> 256 MB written into a 1-byte heap buffer. ReadStream_FALSE calls stream->Read()
> in a loop (64 KB per iteration via kBlockSize). Debugger analysis on a release
> /O1 build (identical codegen to official binary) shows the stream object
> (CInStream) is allocated only 304 bytes (0x130) after _inBuf on the heap.
> The first Read() iteration writes 64 KB of attacker-controlled data starting
> at _inBuf, overwriting the stream object’s vtable pointer after just 304 bytes.
> The second Read() iteration dispatches through the corrupted vtable — a classic
> vtable hijack. The attacker controls the written data (NTFS cluster content
> from the crafted image), so they control the overwritten vtable pointer.
>
>   - Both x86 and x64 builds are affected. On x64, the overflow is reached on
>     any system where the 8 GB _outBuf allocation succeeds (common on modern
>     systems with >= 16 GB RAM).
>   - On Windows, ReadFile fails if it detects an unmapped or guard page in the
>     destination range before copying the controlled bytes. Attackers may need
>     Heap Feng Shui to place _inBuf so the overwrite reaches adjacent objects
>     without immediately faulting.
>   - The NTFS handler is enabled in stock 7z.dll and is registered for .ntfs
>     and .img extensions. However, 7-Zip uses signature-based fallback detection:
>     when the format matching the file extension fails to open, all remaining
>     handlers are tried in signature-priority order. Because the NTFS handler
>     matches on the "NTFS    " signature at byte offset 3 (REGISTER_ARC_I in
>     NtfsHandler.cpp:2889), a crafted NTFS image with any file extension —
>     including .7z, .zip, .rar, or no extension at all — will be opened by the
>     NTFS handler after the extension-matched handler rejects it. This means the
>     attack surface is not limited to files with NTFS-associated extensions.
>   - Triggers during extraction/testing of a compressed file from the crafted
>     image.
>   - No user interaction beyond opening the crafted image.
>
> CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — 8.8 (High)
>
> Affected versions: The GetCuSize() computation has been present since NTFS
> compressed stream support was introduced. All versions through 26.00 are affected.
>
> CWEs
> ----
>     CWE-787: “Out-of-bounds Write”
>     CWE-190: “Integer Overflow or Wraparound”
>
>
> CVE
> ---
>     CVE-2026-48095
>
> Credit
> ------
> This issue was discovered and reported by GHSL team member
> @JarLob (Jaroslav Lobačevski).
>
> Contact
> -------
> You can contact the GHSL team at securitylab () github com, please include a
> reference to GHSL-2026-140 in any communication regarding this issue.


--
        -Alan Coopersmith-                 alan.coopersmith () oracle com
         Oracle Solaris Engineering - https://blogs.oracle.com/solaris