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
- v2-0001-Fix-memory-overrun-of-pg_stat_get_slru.patch (text/x-patch)
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
-
Fix memory overrun when querying pg_stat_slru
- a691a229831a 13.6 landed
- 5f81a480d537 14.2 landed
- a45ed975c58f 15.0 landed