On Tue, Jun 16, 2026 at 1:02 PM Michael Paquier <[email protected]> wrote: > > On Tue, Jun 16, 2026 at 11:15:46AM +0800, Ewan Young wrote: > > The statistics object is then unusable until cleared. With more than > > 65535 items, an assertion-enabled build crashes instead (the Assert in > > mcv_get_match_bitmap()). > > > > The cause is a write/read asymmetry: import_mcv() > > (extended_stats_funcs.c) hands the input item count to > > statext_mcv_import() unbounded, while statext_mcv_deserialize() > > (mcv.c) rejects nitems > STATS_MCVLIST_MAX_ITEMS. This is the same > > family as 6d6348f0329 (CVE-2026-6575) and 0b8fa5fd37b, both of which > > note import_mcv() was not affected by their issue -- the item-count > > bound is a separate, still-open gap. > > Hmm. While I was re-reading statext_mcv_[de]serialize(), my first > thought was if we'd have a risk of out-of-bound read when the data is > loaded back, but I don't see a pattern here. So while the problem is > the same as 6d6348f0329, the consequences are not alarming. The case > where we have more than 65k items is problematic because we can have a > wraparound calculation in statext_mcv_serialize() (close to the > "compute index within the deduplicated array"), meaning that we would > read buggy data, not point at an incorrect memory area. > > > The attached patch adds that bound to import_mcv(), rejecting an > > oversized list with a WARNING before anything is stored. A regression > > test is added to stats_import.sql; "make check" passes. > > Sounds good to me. Thanks for the report.
Thanks for the review! > > Before someone asks, the extstats restore code has inherited this > pattern from the attribute restore code, where functions like > var_eq_const() don't care about the limitation in the number of MCV > items, even with a attstattarget MAX_STATISTICS_TARGET (10k) that caps > the number of MCVs on ANALYZE. So one could inject more items than > 10k, but contrary to the extstats case they can be loaded back without > an error. > -- > Michael Regards, Ewan
