CVE-2026-74751: riscv: lib: Fix ZBB strnlen reading past count boundary
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:
REGL 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects Linux kernel systems using the RISC-V ZBB-optimized strnlen implementation. The vulnerable path is relevant when the input pointer is word-aligned, the count is a multiple of the register word size, and the counted range ends at a page boundary.
What is required to trigger the fault?
The word immediately after the specified count must begin on an unmapped page. Under those conditions, the implementation can load that next word before checking the boundary and fault despite it being outside the requested range.
Is a zero-length strnlen call affected?
No. The count == 0 case already exits before entering the affected loop.
What change fixes the issue?
The fix derives the aligned loop boundary from the last valid byte rather than from s + count, preventing a load from the word immediately following the requested range. It also adds a guard for cases where all valid bytes are in the first word.