| Newsgroups |
gmane.linux.lfs.beyond.book |
| Message-ID |
<[email protected]> |
#23207: 7zip-26.01
-------------------------+-------------------------
Reporter: Bruce Dubbs | Owner: Joe Locash
Type: enhancement | Status: reopened
Priority: high | Milestone: 13.1
Component: BOOK | Version: git
Severity: normal | Resolution:
Keywords: |
-------------------------+-------------------------
Changes (by Douglas R. Reno):
* priority: normal => high
* resolution: fixed =>
* status: closed => reopened
Comment:
{{{
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 [email protected], 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 [email protected], please include
a
> reference to GHSL-2026-140 in any communication regarding this issue.
--
-Alan Coopersmith- [email protected]
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
}}}
This package has now been revealed to be a security update. Reopening and
assigning to SecurityAdvisory for me to handle.
--
Ticket URL: <https://wiki.linuxfromscratch.org/blfs/ticket/23207#comment:3>
BLFS Trac <https://wiki.linuxfromscratch.org/blfs/>
Beyond Linux From Scratch
--
http://lists.linuxfromscratch.org/sympa/info/blfs-book
Unsubscribe: See the above information page