CVE-2026-74751 in Linuxinfo

Summary

by MITRE • 08/26/2026

In the Linux kernel, the following vulnerability has been resolved:

riscv: lib: Fix ZBB strnlen reading past count boundary

The ZBB-optimized strnlen loop loads one word ahead before checking the aligned boundary:

REG_L t1, SZREG(t0) // load next word addi t0, t0, SZREG // advance orc.b t1, t1 bgeu t0, t4, 4f // boundary check AFTER load

where t4 = (s + count) & -SZREG. When s is aligned and count is a multiple of SZREG, t4 equals s + count and the loop loads a full word starting at exactly s + count. If s + count falls on a page boundary with the next page unmapped, this faults.

Fix by computing the aligned boundary from the last valid byte (s + count - 1) instead of s + count. This makes the loop stop at the word containing the last valid byte rather than potentially loading the word after it. The count == 0 case is already handled by the beqz early exit.

Also add a pre-loop guard (bgeu t0, t4) for the case where all valid bytes fit within the first word. With the adjusted boundary, t4 can equal t0, and entering the loop with stale register state from the first-word processing would produce incorrect results.

The final minu clamp ensures the result is still correct when the last loaded word extends past s + count - 1 within the same aligned word.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 08/26/2026

This vulnerability represents a critical out-of-bounds memory read flaw located within the RISC-V architecture implementation of the strnlen function in the Linux kernel, specifically affecting code optimized for the ZBB (Bit Manipulation) instruction set extension. The root cause lies in an incorrect boundary calculation logic during the vectorized or word-aligned processing loop. In the original implementation, the optimization strategy involved loading a full machine word from memory before verifying whether that data falls within the requested length limit. Specifically, the code loads a register with data from address t0 and then increments the pointer by one word size. The boundary check is performed after this load operation to determine if the current position has exceeded the aligned end of the buffer. This architectural decision creates a race condition between memory access and logical bounds checking when specific alignment conditions are met.

The technical flaw manifests under precise geometric conditions where the source string s is naturally aligned to the word size boundary and the specified count parameter is an exact multiple of that same word size. Under these circumstances, the calculated end-of-buffer address t4 becomes exactly equal to s plus count. Consequently, when the loop reaches this final iteration, it attempts to load a full word starting at index s + count. In standard memory management systems, accessing memory addresses beyond the allocated buffer is illegal and typically results in a page fault if that specific virtual memory page has not been mapped into the process address space. This scenario frequently occurs near the end of kernel data structures or user-space buffers where adjacent pages are intentionally left unmapped to detect overflows, thereby turning this logical error into an immediate denial-of-service condition via a kernel panic or segmentation fault.

From a security operations perspective, this vulnerability is classified under CWE-125: Out-of-bounds Read, as it involves reading memory data that lies outside the intended buffer boundaries. The ATT&CK framework categorizes such behavior under techniques related to Discovery and potentially Defense Evasion if an attacker can leverage the resulting instability for further exploitation, although its primary impact here is stability rather than direct privilege escalation. The operational impact of this flaw includes system crashes or kernel panics when strnlen is invoked on carefully crafted inputs that trigger the boundary condition near unmapped pages. This affects any application relying on string length calculations within the kernel space, potentially disrupting services and requiring a full system reboot to restore availability if no watchdog mechanisms are in place.

The resolution implemented by the Linux maintainers addresses this issue through two primary mechanical adjustments to the assembly logic. First, the aligned boundary calculation is shifted from using s + count to using s + count - 1. This ensures that the loop terminates at the word containing the last valid byte rather than attempting to load the subsequent word which may reside in an unmapped page. Second, a pre-loop guard condition was added to handle cases where all valid bytes fit within the first word processed by the optimized path. Without this check, stale register state from initial processing could lead to incorrect results even if no memory fault occurs. Additionally, final masking operations ensure that any partial words loaded beyond the actual string length are correctly zeroed out or ignored, preserving data integrity and preventing information leakage of adjacent kernel memory contents.

Mitigation strategies for organizations running affected kernels involve applying the latest security patches provided by distribution vendors to update the RISC-V specific libc implementations and kernel modules. For environments where immediate patching is not feasible, administrators should monitor system logs for frequent page fault errors or oops messages originating from string handling routines. It is also advisable to review custom drivers or out-of-tree kernel modules that might implement similar optimized string processing logic without adhering to the corrected boundary checks. Regular vulnerability scanning and adherence to strict memory safety practices in low-level code development are essential to prevent recurrence of such off-by-one errors in future software updates.

Responsible

Linux

Reservation

08/15/2026

Disclosure

08/26/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!