public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Vincent Lefevre <vincent@vinc17.net>
To: libc-alpha@sourceware.org
Subject: Re: UB status of snprintf on invalid ptr+size combination?
Date: Mon, 20 Mar 2023 18:00:31 +0100	[thread overview]
Message-ID: <20230320170031.GG203866@cventin.lip.ens-lyon.fr> (raw)
In-Reply-To: <ba3499ce-f296-5368-e9ed-f55526fb4b07@gmail.com>

On 2023-03-20 17:15:49 +0100, Alejandro Colomar wrote:
> On 3/20/23 16:09, Vincent Lefevre wrote:
> > Here's another example where the support of snprintf with a large n
> > argument (larger than the buffer size) may be used:
> > 
> > In GNU MPFR, for our function mpfr_snprintf, we have assumed a
> > behavior analogue to the ISO C behavior. In particular, we use
> > that in our tests in order to check that large values of n are
> > correctly handled. This allowed us to trigger/detect a bug in
> > the choice of the integer types in our implementation:
> > 
> > The test:
> > 
> > https://gitlab.inria.fr/mpfr/mpfr/-/commit/67a75bfe41d3a7f95367ee9e62bd7dfc73e5b395
> > 
> > The bug fix (replacing an int by a size_t in a variable declaration):
> > 
> > https://gitlab.inria.fr/mpfr/mpfr/-/commit/6b8cf3e2bdc285027627281cac230ed932c1b73f
> 
> I don't understand how snprintf(3) helped catch the bug.

It doesn't. *Currently*, MPFR does not use snprintf. With the buggy
version, on a typical 64-bit machine (where int = 32 bits), the size
given to mpfr_snprintf became the value modulo 2^32, so if n is 2^32
(possible as size_t has 64 bits), the implementation of mpfr_snprintf
assumed that the size was 0 (instead of 2^32). Hence the incorrect
behavior.

The test helped to catch this bug because it checks mpfr_snprintf
on this value n = (size_t) UINT_MAX + 1, which is 2^32 here. But in
order not to use much memory, the test is done with a small buffer.
Using a buffer of size n would need 4 GB, and this amount of memory
is not available everywhere.

As MPFR does not currently use snprintf, there would not be any issue
with any snprintf behavior. But in the future, we should use snprintf
(actually gmp_snprintf or similar, but this may call snprintf at the
end) to implement mpfr_snprintf. In such a case, the above test will
no longer work if snprintf aborts just because n is larger than the
buffer size.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

  parent reply	other threads:[~2023-03-20 17:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 19:47 Simon Chopin
2023-03-14 21:39 ` Paul Eggert
2023-03-15  9:22   ` Andreas Schwab
2023-03-15 15:54     ` Siddhesh Poyarekar
2023-03-15 18:34     ` Michael Hudson-Doyle
2023-03-19 14:45     ` manfred
2023-03-19 23:07       ` Vincent Lefevre
2023-03-20 12:05         ` Siddhesh Poyarekar
2023-03-20 12:17           ` Alejandro Colomar
2023-03-20 12:29             ` Siddhesh Poyarekar
2023-03-20 13:36             ` Vincent Lefevre
2023-03-20 13:50           ` Vincent Lefevre
2023-03-20 16:56             ` Siddhesh Poyarekar
2023-03-20 17:36               ` Vincent Lefevre
2023-03-20 15:09       ` Vincent Lefevre
2023-03-20 16:15         ` Alejandro Colomar
2023-03-20 16:33           ` Vincent Lefevre
2023-03-20 17:00           ` Vincent Lefevre [this message]
2023-03-20 17:31             ` Siddhesh Poyarekar
2023-03-20 17:45               ` Vincent Lefevre
2023-03-15 12:39   ` Vincent Lefevre
2023-03-16 10:29     ` Stephan Bergmann
2023-03-18  2:07       ` Vincent Lefevre
2023-03-18  2:30         ` Alejandro Colomar
2023-03-18 10:58           ` Vincent Lefevre
2023-03-18 15:01             ` Andreas Schwab
2023-03-19 22:48               ` Vincent Lefevre
2023-03-19 23:24                 ` Andreas Schwab
2023-03-20  4:10                   ` Vincent Lefevre
2023-03-20  9:19                     ` Andreas Schwab
2023-03-20 10:42                       ` Vincent Lefevre
2023-03-20 10:44                         ` Andreas Schwab

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=20230320170031.GG203866@cventin.lip.ens-lyon.fr \
    --to=vincent@vinc17.net \
    --cc=libc-alpha@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).