From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robins Tharakan <tharakan@gmail.com>
cc: John Naylor <john.naylor@enterprisedb.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17725: Sefault when seg_in() called with a large argument
In-reply-to: <1180064.1671555286@sss.pgh.pa.us>
References: <17725-0a09313b67fbe86e@postgresql.org>
 <CAFBsxsEn0HgkvmX4J3mipZn_gdoF19dj8g-q9WdS76G4QO2cYA@mail.gmail.com>
 <CAEP4nAyECwMeeuzLW=RL4XHwCgxiQgMnfnG4ky-LP1LN82kKaw@mail.gmail.com>
 <1180064.1671555286@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 20 Dec 2022 11:54:46 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1181725.1671555991.1@sss.pgh.pa.us>
Date: Tue, 20 Dec 2022 12:06:31 -0500
Message-ID: <1181726.1671555991@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1181726.1671555991%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> I don't see a crash either, but I can't help observing that this
> input leads to a "seg" struct with "-46" significant digits:
> ...
> So we're invoking sprintf with a fairly insane precision spec:

Actually, it looks like sprintf is not the problem.  This is:

(gdb) 
984                                             buf[10 + n] = '\0';
(gdb) p n
$9 = -46

So first off, we're stomping on something we shouldn't, and
secondly we're failing to nul-terminate buf[], which easily
explains your observed crash at the strcpy a little further
down.  On most platforms strcpy would find a nul byte not
too much further on, which might prevent the worst sorts
of damage, but this is still very ugly.

			regards, tom lane