Improving handling of oversized records in xlogreader.c XLogRecordAssemble() refuses records larger than XLogRecordMaxSize when generating records, but the reader-side only checked a minimal number for xl_tot_len.
A crafted multi-page record with xl_tot_len near UINT32_MAX could bypass the contrecord length checks, overflow allocate_recordbuf()'s size math, and corrupt memory during reassembly (or hit related asserts under cassert). xlogreader.c is updated to check that the received record is never larger than XLogRecordMaxSize, when first receiving the first bytes of xl_tot_len, then again when validating the record header. WAL is a source of data trusted by the server, with CRC32 checksums providing a level of protection before replaying the records if data is corrupted. These limits could be internally reached only with crafted WAL records, which is something that analyzers (named as LLMs) like complaining about these days. 039_end_of_wal.pl is adjusted according to the new maximum limit, a test for XLogRecordMaxSize is added. Author: David Karapetyan <[email protected]> Author: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/calmtjzbddzegvu2o1jnzb3mpvv68pqdskwpauqbvb-35yvk...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/18992dc9d98022a43831da8e1868abf3ce5cd66a Modified Files -------------- src/backend/access/transam/xlogreader.c | 33 +++++++++++++++++++++++++++++++-- src/test/recovery/t/039_end_of_wal.pl | 33 +++++++++++++++++++++++---------- 2 files changed, 54 insertions(+), 12 deletions(-)
