From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 900FE389942E; Tue, 22 Mar 2022 15:16:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 900FE389942E From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug stdio/28989] __snprintf_chk bounds check is too strict Date: Tue, 22 Mar 2022 15:16:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: 2.35 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2022 15:16:06 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28989 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carlos at redhat dot com --- Comment #3 from Carlos O'Donell --- I just reviewed the language in the upcoming C2x standard (N2454) and it remains the same in that the exact language for snprintf is ambiguous about what happens for the bytes between the actual size of 's' and the point at which characters start being discarded i.e. 'n-1'. It is in my opinion a weak argument to say that because C2x is ambiguous th= at we should relax the check in __snprintf_chk. POSIX is clearer in that it states that 'n' is the size of the buffer in 's= ', rather than just the point at which discarding starts to happen. _FORTIFY_SOURCE should allow a strict bounds to catch defects where writes occur beyond 's' but before 'n-1' which may or may not be out-of-bounds. Ye= s, there may be a *practical* false-positive here if the format specifier would not write more than the actual size of 's', and the caller did not want to adjust 'n' because it had a runtime cost. In this case I see two scenarios: (a) Caller doesn't adjust 'n' to match size of 's' because of runtime cost,= and relies on specifier to control how much was written to 's'. - This is risky since in the future the specifier may change. (b) __snprintf_chk becomes more expensive to avoid the case where another restriction (format specifier) would prevent the overflow from happening. Again, this seems like a weak argument. Relying on the format specifier, wh= ich is in no way directly coupled with 'n' is a recipe for a potential future b= ug. The caller may not know the size of 's', in which case it should not use snprintf since there is no inherent benefit. I agree with Andreas here, we can be stricter in __snprintf_chk, it is both cheaper, and safer. --=20 You are receiving this mail because: You are on the CC list for the bug.=