9.8 CVE-2026-52955

In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in crush_decode() A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. If the values in these two fields differ, an out-of-bounds access can occur. This is the case because the first algorithm field (alg) is used to allocate the correct amount of memory for a bucket of this type, while the second algorithm field inside the bucket (b->alg) is used in the subsequent processing. This patch fixes the issue by adding a check that compares alg and b->alg and aborts the processing in case they differ. Furthermore, b->alg is set to 0 in this case, because the destruction of the crush map also uses this field to determine the bucket type, which can again result in an out-of-bounds access when trying to free the memory pointed to by the fields of the bucket. To correctly free the memory allocated for the bucket in such a case, the corresponding call to kfree is moved from the algorithm-specific crush_destroy_bucket functions to the generic crush_destroy_bucket().
https://nvd.nist.gov/vuln/detail/CVE-2026-52955

Categories

CWE-125 : Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer. When an out-of-bounds read occurs, typically the product has already made a separate mistake, such as modifying an index or performing pointer arithmetic that produces an out-of-bounds address. Shorthand for "Out of bounds" read Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues. Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) Use tools that are integrated duringcompilation to insert runtime error-checking mechanismsrelated to memory safety errors, such as AddressSanitizer(ASan) for C/C++ [REF-1518]. Use a language that provides appropriate memory abstractions. The reference implementation code for a Trusted Platform Module does not implement length checks on data, allowing for an attacker to read 2 bytes past the end of a buffer. Out-of-bounds read in IP stack used in embedded systems, as exploited in the wild per CISA KEV. Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data. HTML conversion package has a buffer under-read, allowing a crash Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125) Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122). Chain: series of floating-point precision errors(CWE-1339) in a web browser rendering engine causes out-of-bounds read(CWE-125), giving access to cross-origin data out-of-bounds read due to improper length check packet with large number of specified elements cause out-of-bounds read. packet with large number of specified elements cause out-of-bounds read. out-of-bounds read, resultant from integer underflow large length value causes out-of-bounds read malformed image causes out-of-bounds read OS kernel trusts userland-supplied length value, allowing reading of sensitive information

CWE-131 : Incorrect Calculation of Buffer Size
The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow. This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Use tools that are integrated duringcompilation to insert runtime error-checking mechanismsrelated to memory safety errors, such as AddressSanitizer(ASan) for C/C++ [REF-1518]. Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large. When allocating a buffer for the purpose of transforming, converting, or encoding an input, allocate enough memory to handle the largest possible encoding. For example, in a routine that converts "&" characters to "&" for HTML entity encoding, the output buffer needs to be at least 5 times as large as the input buffer. Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range. For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. When processing structured incoming data containing a size field followed by raw data, identify and resolve any inconsistencies between the size field and the actual size of the data (CWE-130). When allocating memory that uses sentinels to mark the end of a data structure - such as NUL bytes in strings - make sure you also include the sentinel in your calculation of the total amount of memory that must be allocated. Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available. Use sizeof() on the appropriate data type to avoid CWE-467. Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity. This will simplify validation and will reduce surprises related to unexpected casting. Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system. Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations. Chain: Javascript engine code does not perform a length check (CWE-1284) leading to integer overflow (CWE-190) causing allocation of smaller buffer than expected (CWE-131) resulting in a heap-based buffer overflow (CWE-122) Font rendering library does not properlyhandle assigning a signed short value to an unsignedlong (CWE-195), leading to an integer wraparound(CWE-190), causing too small of a buffer (CWE-131),leading to an out-of-bounds write(CWE-787). Chain: integer truncation (CWE-197) causes small buffer allocation (CWE-131) leading to out-of-bounds write (CWE-787) in kernel pool, as exploited in the wild per CISA KEV. substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed substitution overflow: buffer overflow using expansion of environment variables substitution overflow: buffer overflow using a large number of substitution strings transformation overflow: product adds extra escape characters to incoming data, but does not account for them in the buffer length transformation overflow: buffer overflow when expanding ">" to ">", etc. expansion overflow: buffer overflow using wildcards expansion overflow: long pathname + glob = overflow expansion overflow: long pathname + glob = overflow special characters in argument are not properly expanded small length value leads to heap overflow multiple variants needs closer investigation, but probably expansion-based needs closer investigation, but probably expansion-based Chain: Language interpreter calculates wrong buffer size (CWE-131) by using "size = ptr ? X : Y" instead of "size = (ptr ? X : Y)" expression.

References

AFFECTED (from MITRE)

CPE

REMEDIATION

Patch

EXPLOITS

Exploit-db.com

POC Github

Other Nist (github, ...)

CAPEC

Common Attack Pattern Enumerations and Classifications

Cybersecurity needs ?

Strengthen software security from the outset with our DevSecOps expertise

Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.

Discover this offer

Soutenez No Hack Me sur Tipeee