On Fri, Sep 18, 2026 at 1:19 PM Bryan Green <[email protected]> wrote: > > On 4/24/2026 1:44 PM, Haibo Yan wrote: > > On Thu, Apr 23, 2026 at 5:32 AM SCHOEMANS Maxime <[email protected]> > > wrote: > > > >> Hi Haibo, > >> > >> Thanks for creating the CommitFest entry. Could you add Diogo Repas, > >> Zhicheng Luo, and Mahmoud Sakr as authors as well? They wrote the > >> original patch and the underlying algorithm. The earlier CF entry is > >> at https://commitfest.postgresql.org/patch/3821/ for reference. > >> > >> Of course — I’ve added Diogo Repas, Zhicheng Luo, and Mahmoud Sakr as > > authors as we > > > >> Regards, > >> Maxime > >> > > Thanks for the reference. > > > > Best regards, > > Haibo > > > One thing that might be a problem is that rangejoinsel and > multirangejoinsel (0002) look like they use the bounds histogram without > the statistic_proc_security_check() that calc_hist_selectivity does just > above. If I follow it correctly, that runs the cmp/subdiff over another > role's histogram at plan time, before the permission check, which I > believe is what CVE-2017-7484 guarded against. >
Hi Bryan,
Thanks you for catching this.
I independently verified the issue, and the concern is valid for both patch 1
and patch 2. Both `rangejoinsel()` and `multirangejoinsel()` can pass
protected bounds-histogram values to the range support functions during
planning without first calling `statistic_proc_security_check()`.
Both support functions are reachable in this path:
the range comparator through `range_cmp_bounds()`
the subtype-difference function through
`calc_hist_selectivity_scalar()` / `get_position()`
Since the join estimator consumes statistics from both sides, the security
check also needs to be applied to both `vardata1` and `vardata2`.
Attached is v9 with the fix folded into the existing series:
patch 1 adds the security checks to `rangejoinsel()`
patch 2 adds the equivalent checks to `multirangejoinsel()`
patch 3 is unchanged in content
The checks are performed before histogram values are deserialized/used. If
either support function is unsafe for either side, the estimator follows the
existing cleanup path and falls back to the existing default selectivity.
I also added regression coverage to `privileges.sql`, alongside the existing
selfuncs/statistics security tests. The test independently covers both
failure modes — a non-LEAKPROOF comparator and a non-LEAKPROOF
subtype-difference function — for both range and multirange join estimation
under RLS. I verified that reverting only the two source-code security gates
makes those tests fail as expected.
The targeted regression tests and the full regression suite pass with v9.
Thanks again for spotting this.
Regards,
Haibo
>
> --
> Bryan Green
> EDB: https://www.enterprisedb.com
v9-0001-Improve-range-join-selectivity-estimation-for.patch
Description: Binary data
v9-0003-Remove-duplicate-selectivity-functions-between-ra.patch
Description: Binary data
v9-0002-Improve-multirange-join-selectivity-estimation-fo.patch
Description: Binary data
