Re: Unbounded %s in sscanf

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Unbounded %s in sscanf
Date: 2021-07-30 16:03:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> I took another look at this today, and propose to push the attached. The
> pg_dump fix goes all the way back to 9.6 whereas the pg_basebackup fix is from
> 11 and onwards. The adjacent shadowed variable bug in pg_dump is also present
> since 9.6.
> Thoughts?

Generally +1, though I wonder if it'd be prudent to deal with the
shadowed-variable bug by renaming *both* variables. "fname" is
clearly too generic in a function that deals with multiple file

Another thing that is nibbling at the back of my mind is that one
reason we started to use src/port/snprintf.c all the time is that
glibc's *printf functions behave in a very unfriendly fashion when
asked to print text that they think is invalidly encoded, but only
if the format involves an explicit field width spec. I wonder if
we're opening ourselves to similar problems if we start to use
field widths with *scanf. In principle, I think the input text
always ought to be ASCII in these cases, so that there's no hazard.
But is there an interesting security aspect here? That is, if someone
can inject a maliciously-crafted file containing non-ASCII data, what
kind of misbehavior could ensue? It might be that sscanf would just
report failure and we'd give up, which would be fine. But if a
stack overrun could be triggered that way, it'd not be fine.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-07-30 16:04:39 Re: Have I found an interval arithmetic bug?
Previous Message Daniel Gustafsson 2021-07-30 15:48:49 Re: Unbounded %s in sscanf