[PATCH] riscv: lib: Fix address overflow due to large count values in strnlen ZBB path

[Jason Montleon]

On Mon, Aug 24, 2026 at 4:12 AM <gao.rui at zte.com.cn> wrote:
>
>
> Hi Aurelien,
>
> >On 2026-08-19 16:18, gao.rui at zte.com.cn wrote:
> >> Hi all,
> >>
> >> This patch fixes an issue in the RISC-V ZBB optimized strnlen implementation.
> >>
> >> Problem description: When using the ZBB optimized strnlen implementation, passing very large count values (such as SIZE_MAX) can cause address overflow and return incorrect results.
> >>
> >> This issue was observed in device-mapper tests:
> >>
> >> sh-5.2# dmsetup create testname9 --table "0 8 zero"
> >> sh-5.2# cat /sys/block/dm-*/dm/name
> >> testname
> >> sh-5.2# dmsetup remove testname9
> >>
> >> The overflow in strnlen caused failures in string handling during device-mapper operations.
> >>
> >> Patch summary:
> >> - Explicitly introduce the strnlen_generic label.
> >> - Simplify the generic implementation loop.
> >
> >This part should be in a separate patch, separated from the bug fix, and
> >if possible with some benchmark.
>
> I agree, I will split the generic implementation changes into a separate patch and provide benchmark results
> to show the performance impact.

Hi Rui,
Have you made any progress on an updated patch? This problem appears
to be breaking LVM on recent kernel versions. We attempted to boot an
early riscv64 Fedora 45 image with kernel 7.2.7 under QEMU today and
booting failed unexpectedly.

After some digging we found that LVM was broken because the UUID for
dm-0 was truncated. Since we were using Libvirt/QEMU I adjusted the VM
configuration to disable ZBB after which the VM booted successfully.
```
 <cpu mode='custom' match='exact' check='none'>
    <model fallback='forbid'>rv64</model>
    <feature policy='disable' name='zbb'/>
  </cpu>
```

Reproducer: https://gist.github.com/jmontleon/4cca07e6e5e5aa06b6b3e98ced0524e1

Thank you,
Jason Montleon


>
> >> - Add fallback logic in strnlen_zbb to redirect to the generic path when a0 + a1 overflows.
> >> This ensures correct behavior for large count values and SIZE_MAX cases.
> >
> >Is there a way to instead to fix the strnlen_zbb to avoid the fallback?
> >
>
> It is possible to make strnlen_zbb work correctly without fallback, I will reconsider this point:  if the performance loss
> of the non-fallback version turns out to be small, then using the non-fallback code may be acceptable.
>
> Regards,
> Rui
>
>
>
>