aboutsummaryrefslogtreecommitdiff
path: root/src/include/access/commit_ts.h
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-08-07 22:05:27 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-08-07 22:27:13 -0400
commitcc1868799c8311ed1cc3674df2c5e1374c914deb (patch)
tree74a7e286b7cf1791965a03850d0e156a628070e8 /src/include/access/commit_ts.h
parent675c945394b36c2db0e8c8c9f6209c131ce3f0a8 (diff)
downloadpostgresql-cc1868799c8311ed1cc3674df2c5e1374c914deb.tar.gz
postgresql-cc1868799c8311ed1cc3674df2c5e1374c914deb.zip
Fix use-after-free issue in regexp engine.
Commit cebc1d34e taught parseqatom() to optimize cases where a branch contains only one, "messy", atom by getting rid of excess subRE nodes. The way we really should do that is to keep the subRE built for the "messy" child atom; but to avoid changing parseqatom's nominal API, I made it delete that node after copying its fields to the outer subRE made by parsebranch(). It seems that that actually worked at the time; but it became dangerous after ea1268f63, because that later commit allowed the lower invocation of parse() to return a subRE that was also pointed to by some v->subs[] entry. This meant we could wind up with a dangling pointer in v->subs[], allowing a later backref to misbehave, but only if that subRE struct had been reused in between. So the damage seems confined to cases like '((...))...(...\2'. To fix, do what I should have done before and modify parseqatom's API to make it possible for it to remove the caller's subRE instead of the callee's. That's safer because we know that subRE isn't complete yet, so noplace else will have a pointer to it. Per report from Mark Dilger. Back-patch to v14 where the problematic patches came in. Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com
Diffstat (limited to 'src/include/access/commit_ts.h')
0 files changed, 0 insertions, 0 deletions