Tomasz Kantecki 96be77353d igzip: fix use of uninitialized output name buffer
The gzip NAME field is optional, so the header parser can leave the
output name buffer untouched, yet the CLI still read it as a string.
A recycled allocation is not zeroed, so the scan could run past the
end of the buffer and stale contents could be used as the file name.

Terminate the buffer right after allocation and add checks for files
decompressed with no name information.

Signed-off-by: Tomasz Kantecki <tomasz.kantecki@intel.com>
2026-10-23 19:05:49 +01:00
2026-07-16 09:22:51 +01:00
2026-10-23 19:05:31 +01:00
2026-10-23 19:05:31 +01:00
2025-10-20 10:04:01 +01:00
2026-08-21 07:40:59 +01:00
2026-01-28 18:04:04 +00:00
2026-08-20 11:37:14 +01:00
2026-06-19 10:14:09 +01:00
2025-08-08 07:47:35 +00:00
2026-07-01 07:50:33 +01:00
2022-07-18 19:53:53 -07:00
2016-02-24 14:54:34 -07:00
2024-01-09 09:42:48 +00:00
2026-09-30 12:56:15 +01:00
2026-06-17 09:32:00 +01:00
2026-07-01 07:50:33 +01:00
2022-07-18 19:53:53 -07:00

Intel(R) Intelligent Storage Acceleration Library

Continuous Integration Package on conda-forge Coverity Status OpenSSF Scorecard

ISA-L is a collection of optimized low-level functions targeting storage applications. ISA-L includes:

  • Erasure codes - Fast block Reed-Solomon type erasure codes for any encode/decode matrix in GF(2^8).
  • CRC - Fast implementations of cyclic redundancy check. Six different polynomials supported.
    • iscsi32, ieee32, t10dif, ecma64, iso64, jones64, rocksoft64.
  • Raid - calculate and operate on XOR and P+Q parity found in common RAID implementations.
  • Compression - Fast deflate-compatible data compression.
  • De-compression - Fast inflate-compatible data compression.
  • igzip - A command line application like gzip, accelerated with ISA-L.

Also see:

API Usage Notes

Parameters passed to ISA-L functions are not fully validated. In particular, NULL pointers and other invalid inputs are not checked and may result in undefined behavior. Callers are responsible for ensuring all arguments are valid before invoking library functions.

Building ISA-L

Prerequisites

  • Make: GNU 'make' or 'nmake' (Windows).
  • Optional: Building with autotools requires autoconf/automake/libtool packages.
  • Optional: Manual generation requires help2man package.

x86_64:

  • Assembler: nasm. 2.14.01 minimum version required support).
  • Compiler: gcc, clang, icc or VC compiler.

aarch64:

  • Assembler: gas v2.24 or later.
  • Compiler: gcc v10.1 or later.

RISC-V 64:

  • Portable base functions:
    • Supported by most C compilers.
  • For RISC-V Vector (RVV) support:
    • Assembler: gas v2.39 or later.
    • Compiler: gcc v12.1 or later.

other:

  • Compiler: Portable base functions are available that build with most C compilers.

Autotools

To build and install the library with autotools it is usually sufficient to run:

./autogen.sh
./configure
make
sudo make install

Makefile

To use a standard makefile run:

make -f Makefile.unx

Windows

On Windows use nmake to build dll and static lib:

nmake -f Makefile.nmake

or see details on setting up environment here.

CMake (Experimental)

Refer to cmake/README.md file.

Other make targets

Other targets include:

  • make check : create and run tests
  • make tests : create additional unit tests
  • make perfs : create included performance tests
  • make ex : build examples
  • make other : build other utilities such as compression file tests
  • make doc : build API manual

DLL Injection Attack

Problem

The Windows OS has an insecure predefined search order and set of defaults when trying to locate a resource. If the resource location is not specified by the software, an attacker need only place a malicious version in one of the locations Windows will search, and it will be loaded instead. Although this weakness can occur with any resource, it is especially common with DLL files.

Solutions

Applications using libisal DLL library may need to apply one of the solutions to prevent from DLL injection attack.

Two solutions are available:

  • Using a Fully Qualified Path is the most secure way to load a DLL
  • Signature verification of the DLL

Resources and Solution Details

S
Description
No description provided
Readme BSD-3-Clause 6.5 MiB
Languages
C 57.6%
Assembly 39.2%
Makefile 1.1%
CMake 1.1%
Shell 0.6%
Other 0.4%