[PATCH v2 0/2] lib/vsprintf: pointer handling fixes for bstr_printf() and vbin_printf()

[PATCH v2 0/2] lib/vsprintf: pointer handling fixes for bstr_printf() and vbin_printf()

[Josh Law]

These patches address multiple bugs in vsprintf pointer handling


Patch one: Regards argument pointer advancement in bstr_printf(),
when the buffer is full..
Patch two: Fixes a OOB write in vbin_printf() when size is 0

Josh Law (2):
  lib/vsprintf: always advance args in bstr_printf() pointer path
  lib/vsprintf: fix OOB write in vbin_printf() when size is zero

 lib/vsprintf.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)


Changes since V1:
Dropped 2 patches, probably not needed.
For patch 2: Instead of using else if (end > (char *)bin_buf),
instead guard size with else if (size) /* do nothing if size is zero */
(suggested by steven Rostedt)
-- 
2.34.1

[PATCH v2 1/2] lib/vsprintf: always advance args in bstr_printf() pointer path

[Josh Law]

When the output buffer is full (str >= end), bstr_printf() skips
advancing the args pointer past the pre-rendered pointer string in
bin_buf. This causes all subsequent format specifiers to read from
the wrong position, corrupting the rest of the output.

Always compute the string length and advance args regardless of
whether there is space to copy into the output buffer.

Signed-off-by: Josh Law <objecting@objecting.org>
---
 lib/vsprintf.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 800b8ac49f53..7898fb998b21 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -3389,14 +3389,15 @@ int bstr_printf(char *buf, size_t size, const char *fmt_str, const u32 *bin_buf)
 					break;
 				}
 				/* Pointer dereference was already processed */
+				len = strlen(args);
 				if (str < end) {
-					len = copy = strlen(args);
+					copy = len;
 					if (copy > end - str)
 						copy = end - str;
 					memcpy(str, args, copy);
-					str += len;
-					args += len + 1;
 				}
+				str += len;
+				args += len + 1;
 			}
 			if (process)
 				str = pointer(fmt.str, str, end, get_arg(void *), spec);
-- 
2.34.1

Re: [PATCH v2 1/2] lib/vsprintf: always advance args in bstr_printf() pointer path

[Krzysztof Kozlowski]

On 30/03/2026 21:34, Josh Law wrote:
> When the output buffer is full (str >= end), bstr_printf() skips
> advancing the args pointer past the pre-rendered pointer string in
> bin_buf. This causes all subsequent format specifiers to read from
> the wrong position, corrupting the rest of the output.
> 
> Always compute the string length and advance args regardless of
> whether there is space to copy into the output buffer.
> 
> Signed-off-by: Josh Law <objecting@objecting.org>

NAK

Questionably origin (multiple identities used), questionable content.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] lib/vsprintf: always advance args in bstr_printf() pointer path

[Steven Rostedt]

On Tue, 31 Mar 2026 09:26:46 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 30/03/2026 21:34, Josh Law wrote:
> > When the output buffer is full (str >= end), bstr_printf() skips
> > advancing the args pointer past the pre-rendered pointer string in
> > bin_buf. This causes all subsequent format specifiers to read from
> > the wrong position, corrupting the rest of the output.
> > 
> > Always compute the string length and advance args regardless of
> > whether there is space to copy into the output buffer.
> > 
> > Signed-off-by: Josh Law <objecting@objecting.org>  
> 
> NAK
> 
> Questionably origin (multiple identities used), questionable content.

Can you expand further on this complaint?

-- Steve

Re: [PATCH v2 1/2] lib/vsprintf: always advance args in bstr_printf() pointer path

[Kuan-Wei Chiu]

Hi Steven,

On Tue, Mar 31, 2026 at 10:47:08AM -0400, Steven Rostedt wrote:
> On Tue, 31 Mar 2026 09:26:46 +0200
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
> > On 30/03/2026 21:34, Josh Law wrote:
> > > When the output buffer is full (str >= end), bstr_printf() skips
> > > advancing the args pointer past the pre-rendered pointer string in
> > > bin_buf. This causes all subsequent format specifiers to read from
> > > the wrong position, corrupting the rest of the output.
> > > 
> > > Always compute the string length and advance args regardless of
> > > whether there is space to copy into the output buffer.
> > > 
> > > Signed-off-by: Josh Law <objecting@objecting.org>  
> > 
> > NAK
> > 
> > Questionably origin (multiple identities used), questionable content.
> 
> Can you expand further on this complaint?
>
You can check out the related discussion in this email thread [1]. It's
mainly about a recent controversy regarding AI-generated kernel
contributions.

[1]: https://lore.kernel.org/lkml/cbd0aafa-bd45-4f4d-a2dd-440473657dba@lucifer.local/

Regards,
Kuan-Wei

Re: [PATCH v2 1/2] lib/vsprintf: always advance args in bstr_printf() pointer path

[Josh Law]

---- On Thu, 02 Apr 2026 04:47:45 +0100 visitorckw@gmail.com wrote ----


> Hi Steven,
>
> On Tue, Mar 31, 2026 at 10:47:08AM -0400, Steven Rostedt wrote:
> > On Tue, 31 Mar 2026 09:26:46 +0200
> > Krzysztof Kozlowski wrote:
> >
> > > On 30/03/2026 21:34, Josh Law wrote:
> > > > When the output buffer is full (str >= end), bstr_printf() skips
> > > > advancing the args pointer past the pre-rendered pointer string in
> > > > bin_buf. This causes all subsequent format specifiers to read from
> > > > the wrong position, corrupting the rest of the output.
> > > >
> > > > Always compute the string length and advance args regardless of
> > > > whether there is space to copy into the output buffer.
> > > >
> > > > Signed-off-by: Josh Law
>
> > >
> > > NAK
> > >
> > > Questionably origin (multiple identities used), questionable content.
> >
> > Can you expand further on this complaint?
> >
> You can check out the related discussion in this email thread [1]. It's
> mainly about a recent controversy regarding AI-generated kernel
> contributions.
>
> [1]:
> https://lore.kernel.org/lkml/cbd0aafa-bd45-4f4d-a2dd-440473657dba@lucifer.local/[https://lore.kernel.org/lkml/cbd0aafa-bd45-4f4d-a2dd-440473657dba@lucifer.local/]
>
> Regards,
> Kuan-Wei


Hello, he is aware of that thread, it has been resolved as of now.

Re: [PATCH v2 1/2] lib/vsprintf: always advance args in bstr_printf() pointer path

[Steven Rostedt]

On Thu, 02 Apr 2026 09:03:39 +0100
Josh Law <objecting@objecting.org> wrote:

> > > > Questionably origin (multiple identities used), questionable content.  
> > >
> > > Can you expand further on this complaint?
> > >  
> > You can check out the related discussion in this email thread [1]. It's
> > mainly about a recent controversy regarding AI-generated kernel
> > contributions.
> >
> > [1]:
> > https://lore.kernel.org/lkml/cbd0aafa-bd45-4f4d-a2dd-440473657dba@lucifer.local/[https://lore.kernel.org/lkml/cbd0aafa-bd45-4f4d-a2dd-440473657dba@lucifer.local/]
> >
> > Regards,
> > Kuan-Wei  
> 
> 
> Hello, he is aware of that thread, it has been resolved as of now.

Yes Krzysztof contacted me offline about it. I also communicated with Josh.
I had a video call with Josh which proved he is not a bot. He's just
someone that needs a bit of guidance.

Thanks,

-- Steve

[PATCH v2 2/2] lib/vsprintf: fix OOB write in vbin_printf() when size is zero

[Josh Law]

When vbin_printf() is called with size==0, end equals bin_buf and
the else branch writes end[-1], which is one byte before the buffer.

Guard the write so it only happens when the buffer is non-empty.

Signed-off-by: Josh Law <objecting@objecting.org>
---
 lib/vsprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 7898fb998b21..b879babaf8c2 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -3234,7 +3234,7 @@ int vbin_printf(u32 *bin_buf, size_t size, const char *fmt_str, va_list args)
 					      spec);
 				if (str + 1 < end)
 					*str++ = '\0';
-				else
+				else if (size) /* do nothing if size is zero */
 					end[-1] = '\0'; /* Must be nul terminated */
 			}
 			/* skip all alphanumeric pointer suffixes */
-- 
2.34.1