CVE-2026-122330 in c-blosc2
Summary
by MITRE • 11/05/2026
Blosc c-blosc2 before 3.5.0 contains a divide-by-zero vulnerability in blosc2_schunk_get_slice_buffer() in blosc/schunk.c that allows attackers to crash applications by supplying crafted frames with unchecked zero chunksize or blocksize values. Attackers can provide a malicious Blosc2 frame opened via blosc2_schunk_open() or blosc2_schunk_from_buffer() and read as a slice, raising SIGFPE and terminating the process.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in c-blosc2 prior to version 3.5.0 represents a critical arithmetic error within the library's data handling mechanisms, specifically located in the blosc2_schunk_get_slice_buffer function found in the schunk.c source file. This flaw stems from an insufficient validation of input parameters during the processing of compressed data frames. When an application utilizes functions such as blosc2_schunk_open or blosc2_schunk_from_buffer to load a Blosc2 frame, and subsequently attempts to read it as a slice using get_slice_buffer, the library fails to verify that critical dimensional values are non-zero. Specifically, if the chunksize or blocksize attributes within the crafted metadata of the input file are set to zero, the internal arithmetic operations perform an illegal division by zero operation. This mathematical anomaly triggers a floating-point exception signal, commonly known as SIGFPE on Unix-like systems, which results in the immediate termination of the host process without any graceful error handling or recovery mechanism.
From a technical perspective, this issue is classified under CWE-369, which denotes Divide By Zero errors. The root cause lies in the absence of boundary checks for structural integrity parameters before they are utilized in computational logic. In secure software development practices, inputs derived from external sources must always be validated against expected constraints to prevent undefined behavior. Here, the library assumes that chunksize and blocksize will always contain positive integer values representing valid data dimensions. However, because these values can be manipulated by an attacker providing a maliciously constructed file or buffer, the assumption is violated. The lack of pre-condition checks allows invalid state transitions within the decompression engine, leading directly to application instability. This type of flaw is particularly dangerous in environments where c-blosc2 is used for high-throughput data processing pipelines, as it can cause service disruptions with minimal effort from an adversary who merely needs to supply a specially formatted input file.
The operational impact of this vulnerability is primarily centered on availability and system stability rather than confidentiality or integrity. By exploiting the divide-by-zero condition, an attacker can achieve remote code execution denial-of-service conditions against any application that integrates c-blosc2 for data compression tasks. If the affected software runs with elevated privileges or handles sensitive workloads, a crash could lead to significant downtime, loss of unsaved state, or cascading failures in dependent services. While the immediate effect is a process termination via SIGFPE, repeated exploitation attempts can exhaust system resources if not properly contained by external watchdogs or container limits. Furthermore, in long-running daemon processes that rely on continuous data ingestion from untrusted sources, this vulnerability presents a straightforward vector for persistent disruption of service availability.
Mitigation strategies should focus primarily on upgrading the c-blosc2 library to version 3.5.0 or later, where the developers have implemented proper input validation and error handling routines to catch these invalid parameters before they reach arithmetic operations. For organizations unable to immediately patch their dependencies, defensive programming practices within the application layer are recommended. Developers should implement explicit checks for chunksize and blocksize values being greater than zero prior invoking any blosc2_schunk functions that process external data buffers or files. Additionally, integrating runtime protection mechanisms such as Address Sanitizers during testing phases can help identify similar arithmetic flaws early in the development lifecycle. Monitoring system logs for SIGFPE signals may also aid in detecting exploitation attempts in production environments where patching is delayed.
This vulnerability aligns with ATT&CK technique T1499, Endpoint Denial of Service, as it involves manipulating a component to cause resource exhaustion or service disruption through application crashes. It also reflects common weaknesses associated with CWE-20 Improper Input Validation and CWE-755: Improper Handling of Exceptional Conditions. Security teams should prioritize the remediation of this issue in all systems utilizing c-blosc2 for data serialization, particularly those exposed to untrusted input streams or public-facing APIs that accept compressed data payloads. Regular audits of third-party library versions and adherence to secure coding standards are essential to prevent similar arithmetic vulnerabilities from impacting operational continuity.