Re: [PATCH 2/2] lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()

[Vincent Mailhol]

On Thu. 23 Jul. 2026 at 01:01, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 22 Jul 2026 23:04:53 +0200 Vincent Mailhol <mailhol@xxxxxxxxxx> wrote:
>
> > ucs2_strnlen() checks the current character before checking whether the
> > caller-provided maximum length has been reached. If the input is not
> > NUL-terminated within that bound, the loop can read one ucs2_char_t past
> > the limit.
>
> Is there a known way of hitting this from userspace?

I don't see an easy way to exploit this weakness. For an actual kernel
oops to occur, the buffer would need to be at the very end of a page
so that the off-by-one read crosses a page boundary and faults. I
cannot tell whether this is a plausible scenario.

The next worst scenario I can think of would be some kind of timing
attack on CPU branch prediction to leak whether the first ucs2_char_t
past the limit is NUL. That does not seem to provide much leverage in
practice.

So the remaining visible impact would most likely be a KASAN warning.
Although not tested, it seems that admins can trigger this at will by
writing to EFI variables. For normal users, I could not find an easy
path.

> If so, and if the
> effect is at all serious then we should prepare a backportable fix
> against current mainline - that whitespace tweaking patch can come
> later.

Regardless of the above, I agree that it is safer to backport. I will
reorder the series, with the fix first and the tabulation cleanup
next, and add a Cc: stable tag.

> Also, AI review points at a few possible pre-existing problems in there
> which might interest you:
>         https://sashiko.dev/#/patchset/20260722-fix-ucs2_strnlen-v1-0-ba5bade2b026@xxxxxxxxxx

None of these seem to be addressable by some trivial one-liner fixes
and I already have my TODO list. Sorry but I do not plan to invest
more time investigating those other issues.


Yours sincerely,
Vincent Mailhol