Re: BUG #17280: global-buffer-overflow on select from pg_stat_slru

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: a.kozhemyakin@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2021-11-12T07:25:46Z
Lists: pgsql-bugs

Attachments

At Thu, 11 Nov 2021 17:08:34 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Thu, Nov 11, 2021 at 12:19:09PM +0900, Kyotaro Horiguchi wrote:
> > I'm not sure which is easier to read, but it might be a bit hard since
> > the conditino term in not mention counter itself. I don't object to
> > that way.  And, yes SLRU_NUM_ELEMENTS cannot be used here:p
> > 
> > The attached is the first way in the choices.
>
> That looks fine.
> 
> Also, what do you think about adding a test in sysviews.sql? This
> could be as simple as that:
> SELECT count(*) > 0 AS ok FROM pg_stat_slru;

Rahter it is touching only pg_stat_wal and pg_stat_walreceiver among
42 pg_stat_* views. However I agree to it is good to add it for the
reason mentioned below.

> I am not sure if the buildfarm animals running valgrind would have
> caught this issue, but having something would be better than nothing
> for this case.

Valgrind didn't detect that for me (-O0).  The address area accessed
by the overun is allocated to other variables.  That being said.  I
agree that causing access to the full range of the variable should
help checker tools. And that ends in a time shorter than a blink.

Please find the attached.

regrds.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Commits

  1. Fix memory overrun when querying pg_stat_slru