Re: [PATCH 2/2] platform/x86: hp-bioscfg: fix heap OOB read and buffer desync in hp_get_string_from_buffer()

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

On Sat, 19 Sep 2026, Muhammad Bilal wrote:

> Confirmed, you're right about the redundancy.
> 
> utf16s_to_utf8s() takes src by value, so it can't advance the caller's
> src pointer. The second loop then restarts from the same position and
> overwrites everything the conversion just wrote, using dst[i] = *src,
> a raw truncating cast with no UTF-8 encoding. So step 2 is currently
> dead work, and the function is ASCII-only in practice: any character
> above 0x7f gets truncated to garbage instead of being properly
> encoded.
> 
> Two ways to fix that, and I'd like your preference before I send
> anything more for it:
> 
> (a) Keep utf16s_to_utf8s() as the real conversion, and rewrite the
> second loop to do escaping as a pass over its UTF-8 output instead of
> re-deriving from UTF-16 src.

Not exactly this, but somewhere there.

You should not try to build the escaping nor utf-8 parsing/length 
calculation within the driver but use generic code for that.

To give some directions...

There seems to be some escaping function in lib/string_helpers.c but since 
we're dealing with an UTF-8 string here, there might not be a readily 
available function for string inputs/outputs.

escape_space() seems to also cover escaping \v, which wasn't among the 
characters this driver escapes. You might need to check that particular 
character in driver before calling the library's escape funtion though 
I'm more thinking along the lines of not escaping it was an oversight from 
the original submitter (given the questionable quality of this driver to 
begin with).

utf8clen() seems to exists, but is currently in inconvinient place (and 
already duplicated so it should be placed into some header anyway).

> (b) Drop utf16s_to_utf8s() entirely if ASCII-only was always the
> intent, and keep only the manual loop, fixing its bounds instead..

I think ASCII only was not the intent, but it just happens to work in 
many cases which is why this has survived so far.

-- 
 i.