CVE-2026-59143 in Data::RoaringBitmap::Shared
Summary
by MITRE • 07/21/2026
Data::RoaringBitmap::Shared versions before 0.02 for Perl allow an out-of-bounds read via an unvalidated container offset and cardinality in rb_contains_locked.
The attach-time validator rb_validate_header checks the header scalars and region layout against the file size, but does not validate the bucket contents it then trusts. rb_contains_locked forms a container pointer as pool + container_off * 8192 from a raw file-stored offset and then searches over a file-stored cardinality, neither bounded against the container pool capacity or the fixed 8192-byte slot size.
A local peer that can write the backing file can leave the header valid while poisoning a bucket, so the next membership query dereferences a file-controlled wild pointer and scans a file-controlled count, reading adjacent memory or crashing the process.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability in Data::RoaringBitmap::Shared versions prior to 0.02 represents a critical out-of-bounds read condition that stems from inadequate input validation during the bitmap container processing phase. This flaw occurs when the library performs membership queries using the rb_contains_locked function, which processes container data structures without proper bounds checking against the underlying memory layout. The issue manifests as a deserialization vulnerability where maliciously crafted container offsets and cardinality values can cause arbitrary memory access patterns.
The root cause lies in the insufficient validation performed during the attachment phase of the library. While rb_validate_header performs basic checks on header scalars and region layout against the file size, it fails to validate the integrity of the bucket contents that follow the header structure. This validation gap allows attackers to manipulate the container data without triggering immediate failure conditions, as the header validation passes even when the subsequent bucket data is corrupted or poisoned.
The technical implementation flaw occurs within rb_contains_locked function where container pointers are constructed using pool + container_off * 8192 arithmetic operations based on raw file-stored offset values. This approach does not verify that the calculated pointer remains within valid memory bounds relative to the container pool capacity or the fixed 8192-byte slot size constraints. Additionally, the function relies on file-stored cardinality values for loop iteration limits without validating these against the actual container capacity, creating a scenario where memory access can extend beyond intended boundaries.
This vulnerability creates significant operational impact as it enables local privilege escalation through memory disclosure attacks. An attacker with write access to the backing file can poison container buckets while maintaining valid header structures, allowing subsequent membership queries to dereference wild pointers and scan arbitrary memory regions. The attack vector specifically targets local peers who can modify the shared bitmap files, potentially leading to information disclosure or process crashes depending on the memory layout and access patterns.
The vulnerability aligns with CWE-129 Input Validation and Output Encoding, specifically addressing weak validation of array indices and improper bounds checking in data structures. From an ATT&CK perspective, this represents a privilege escalation technique through file modification, falling under T1074 Data Suspicious File and T1548 Abuse of Cloud Resources where local file corruption leads to memory access violations. The attack requires local write access to the backing file but does not necessitate elevated privileges beyond basic filesystem permissions.
Mitigation strategies should focus on implementing comprehensive bounds checking during container processing, including validation of container offsets against pool capacity and cardinality values against slot size limitations. The library should enforce strict validation of all container data structures before processing, ensuring that calculated pointers remain within valid memory regions and loop iterations respect actual container boundaries. Additionally, input sanitization measures should be implemented to prevent trusted file data from bypassing validation checks, requiring explicit bounds verification for all memory access operations in the rb_contains_locked function and similar container processing routines.
The recommended fix involves modifying the attachment validation process to include comprehensive bucket content validation, implementing proper pointer arithmetic bounds checking, and ensuring that file-stored cardinality values are validated against container capacity constraints. This approach addresses the fundamental design flaw while maintaining backward compatibility with legitimate use cases for the Data::RoaringBitmap::Shared library functionality.