public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Benjamin A. Beasley <code@musicinmybrain.net>
To: git-commits@fedoraproject.org
Subject: [rpms/stb] epel9: Patch stb_sprintf: security fix for CVE-2026-79516
Date: Thu, 10 Sep 2026 18:08:41 GMT	[thread overview]
Message-ID: <178906372192.1.6006454842570978458.rpms-stb-4c8719e6ca36@fedoraproject.org> (raw)

            A new commit has been pushed.

            Repo   : rpms/stb
            Branch : epel9
            Commit : 4c8719e6ca3622447f2cf4ef94fbb29a42d19313
            Author : Benjamin A. Beasley <code@musicinmybrain.net>
            Date   : 2026-09-10T19:06:58+01:00
            Stats  : +51/-0 in 2 file(s)
            URL    : https://src.fedoraproject.org/rpms/stb/c/4c8719e6ca3622447f2cf4ef94fbb29a42d19313?branch=epel9

            Log:
            Patch stb_sprintf: security fix for CVE-2026-79516

- Fixes RHBZ#2531291; Fixes RHBZ#2531290

---
diff --git a/1995.patch b/1995.patch
new file mode 100644
index 0000000..1e279cd
--- /dev/null
+++ b/1995.patch
@@ -0,0 +1,39 @@
+From 1fd7ff9fdb97f301264226302a4d70b1074a6b66 Mon Sep 17 00:00:00 2001
+From: Brandon Barrante <aetherai@aethersystems.net>
+Date: Sun, 6 Sep 2026 19:04:39 -0400
+Subject: [PATCH] stb_sprintf: don't write buf[-1] on snprintf(buf, 0, ...)
+ (fixes #1963)
+
+The top gate in STB_SPRINTF_DECORATE(vsnprintf) only entered the count-only path when both count == 0 AND buf was NULL. A caller passing a valid buffer with count == 0 (the shape callers use to ask 'how big would this be?') fell through to the else branch, computed l = (int)(c.buf - buf) = 0, hit the l >= count clamp, dropped to l = count - 1 = -1, and executed buf[-1] = 0 -- one byte out-of-bounds before the caller's buffer.
+
+The C standard is explicit that snprintf(buf, 0, ...) must not write. glibc, musl and the BSD snprintf all skip the null terminator when count == 0.
+
+Extend the gate to count <= 0 so the count-only path handles both the null-buf and the non-null-buf cases the same way. The count-only path uses stbsp__count_clamp_callback which only accumulates length and never dereferences buf, so it's safe with buf == NULL. Behavior for count > 0 is unchanged.
+
+Verified under ASan/UBSan on master 2c980bb5: stack layout puts pad_after immediately before buf; before the fix, snprintf(buf, 0, ...) sets pad_after[15] to 0x00; after the fix it stays as 'B'. Positive controls (normal snprintf, truncation, count=1, count=0-with-null-buf) all still pass.
+
+Fixes: #1963
+Reported-by: JerryGW (github.com/JerryGW)
+Signed-off-by: Brandon Barrante <aetherai@aethersystems.net>
+---
+ stb_sprintf.h | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/stb_sprintf.h b/stb_sprintf.h
+index ca432a6bca..6625d6eed0 100644
+--- a/stb_sprintf.h
++++ b/stb_sprintf.h
+@@ -1431,8 +1431,12 @@ STBSP__PUBLICDEF int STB_SPRINTF_DECORATE( vsnprintf )( char * buf, int count, c
+ {
+    stbsp__context c;
+ 
+-   if ( (count == 0) && !buf )
++   if ( count <= 0 )
+    {
++      // C standard: snprintf(buf, 0, ...) writes nothing, returns the count
++      // the full output would have taken. Handle this whether or not the
++      // caller passed a valid buffer -- writing buf[count - 1] with count == 0
++      // is an out-of-bounds write before the caller's buffer.
+       c.length = 0;
+ 
+       STB_SPRINTF_DECORATE( vsprintfcb )( stbsp__count_clamp_callback, &c, c.tmp, fmt, va );

diff --git a/stb.spec b/stb.spec
index 10fe46f..dd27fd0 100644
--- a/stb.spec
+++ b/stb.spec
@@ -226,6 +226,18 @@ Patch:          %{url}/pull/1863.patch
 # https://github.com/nothings/stb/issues/1929
 Patch:          issue-1929.patch
 
+# stb_sprintf: don't write buf[-1] on snprintf(buf, 0, ...) (fixes #1963)
+# https://github.com/nothings/stb/pull/1995
+#
+# Fixes CVE-2026-79516:
+#
+# [SECURITY] stbsp_snprintf with count=0 writes null terminator before buffer
+# https://github.com/nothings/stb/issues/1963
+#
+# Patch rejected upstream without comment, presumably because the PR was
+# drafted with AI/LLM assistance.
+Patch:          %{url}/pull/1995.patch
+
 %global stb_c_lexer_version 0.12
 %global stb_connected_components_version 0.96
 %global stb_divide_version 0.94

                 reply	other threads:[~2026-09-10 18:08 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178906372192.1.6006454842570978458.rpms-stb-4c8719e6ca36@fedoraproject.org \
    --to=code@musicinmybrain.net \
    --cc=git-commits@fedoraproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox