epam
bug: vulnerable broken postgresql search with range partition table using inner join ordinary non-structure table
Summary vulnerable broken postgresql search with range partition table using inner join ordinary non-structure table
Steps to Reproduce
- Bingo cartridge:
- SQL: select teststruct.regId from teststruct inner join substancename on teststruct.regId = substancename .chemid where teststruct.molfile @('000-502-36.mol ChemDraw08272111072D
11 11 0 0 0 0 0 0 0 0999 V2000
0.3572 0.0000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
0.3572 -0.8250 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
1.0717 -1.2375 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
1.7862 -0.8250 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
1.7862 0.0000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
1.0717 0.4125 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
-0.3572 0.4125 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
-1.0717 0.0000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0
-0.3572 1.2375 0.0000 N 0 0 0 0 0 0 0 0 0 0 0 0
-1.7862 0.4125 0.0000 O 0 0 0 0 0 0 0 0 0 0 0 0
-1.0717 -0.8250 0.0000 O 0 0 0 0 0 0 0 0 0 0 0 0
1 2 2 0
2 3 1 0
3 4 2 0
4 5 1 0
5 6 2 0
6 1 1 0
1 7 1 0
7 8 1 0
7 9 1 6
8 10 1 0
8 11 2 0
M END
','')::bingo.exact;
Expected behavior regId result
Actual behavior vulnerable broken: sometimes can obtained correct result, and the others got error message: "server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request."
Environment details:
- CentOS 64 2009: vulnerable_broken_range_partition_table_postgresql.txt
Attachments the attachment is the text file which contains sql clauses for create substancename table and range partition table teststruct.
### Memory Leakage May Cause Postgres Server To Collapse
In order to find out what cause this phenomenon，I built a debug version of postgres-REL_15_7 and an indigo master debug version, It seems that the memory leakage cause the postgres server to collapse. Reason: Pieces of postgres code in src/backend/utils/adt/expandedrecord.c line 491
if (copy && tuple)
{
oldcxt = MemoryContextSwitchTo(erh->hdr.eoh_context);
newtuple = heap_copytuple(tuple);
newflags |= ER_FLAG_FVALUE_ALLOCED;
MemoryContextSwitchTo(oldcxt);
/* We can now flush anything that detoasting might have leaked. */
if (expand_external)
MemoryContextReset(erh->er_short_term_cxt);
}
I found: if *erh varable did not change after calling heap_copytuple，we could get result，if it changed, server would be collapsed; while the method heap_copytuple should not change the *erh varable. For example (collapsed) : Before calling heap_copytuple: *erh : {hdr = {vl_len_ = -1, eoh_methods = 0xa721d0 <ER_methods>, eoh_context = 0x2ae7900, eoh_rw_ptr = "\001\003\030z\256\002\000\000\000", eoh_ro_ptr = "\001\002\030z\256\002\000\000\000"}, er_magic = 1384727874, flags = 0, er_decltypeid = 49464, er_typeid = 49464, er_typmod = -1, er_tupdesc = 0x7f04c4520318, er_tupdesc_id = 2, dvalues = 0x2ae7ae8, dnulls = 0x2ae7af8, nfields = 2, flat_size = 0, data_len = 0, hoff = 0, hasnull = false, fvalue = 0x0, fstartptr = 0x0, fendptr = 0x0, er_short_term_cxt = 0x0, er_dummy_header = 0x0, er_domaininfo = 0x0, er_mcb = {func = 0x819c60 <ER_mc_callback>, arg = 0x2ae7a18, next = 0x0}} *erh->hdr.eoh_context: {type = T_AllocSetContext, isReset = false, allowInCritSection = false, mem_allocated = 8192, methods = 0xab35a0 <AllocSetMethods>, parent = 0x2afe190, firstchild = 0x0, prevchild = 0x0, nextchild = 0x0, name = 0xa720db "expanded record", ident = 0x0, reset_cbs = 0x2ae7ad0} After calling heap_copytuple: *erh: {hdr = {vl_len_ = 1121, eoh_methods = 0xa70000, eoh_context = 0x2ae7a30, eoh_rw_ptr = "\204\021\000\000\377\377\377\377\070\301", eoh_ro_ptr = "\000\000\377\377\377\377\000\000\002"}, er_magic = 4384, flags = 758132784, er_decltypeid = 758263861, er_typeid = 1831745075, er_typmod = 168651887, er_tupdesc = 0x3830776172446d65, er_tupdesc_id = 3976732558316681010, dvalues = 0x31200a0d0a0d4432, dnulls = 0x2030202031312031, nfields = 538980384, flat_size = 2314903123005546528, data_len = 2321950000669532208, hoff = 808464982, hasnull = 48, fvalue = 0x3735332e30202020, fstartptr = 0x302e302020202032 <Address 0x302e302020202032 out of bounds>, fendptr = 0x3020202020303030 <Address 0x3020202020303030 out of bounds>, er_short_term_cxt = 0x204320303030302e, er_dummy_header = 0x2020302020302020, er_domaininfo = 0x2030202030202030, er_mcb = {func = 0x3020203020203020, arg = 0x2020302020302020, next = 0x20200a0d30202030}} *erh->hdr.eoh_context：{type = 4484, isReset = 255, allowInCritSection = 255, mem_allocated = 18446744069414633784, methods = 0x18000200020000, parent = 0x2d30303000001120, firstchild = 0x6d2e36332d323035, prevchild = 0x684320200a0d6c6f, nextchild = 0x3830776172446d65, name = 0x3730313131323732 <Address 0x3730313131323732 out of bounds>, ident = 0x31200a0d0a0d4432 <Address 0x31200a0d0a0d4432 out of bounds>, reset_cbs = 0x2030202031312031}
Postgres build options : OS :CentOS 2009 Configure : ../postgres-REL_15_7/configure --prefix=/usr/local/postgres --with-openssl --with-zstd --with-lz4 --with-ldap --with-libxml --with-libxslt --with-icu --with-gssapi --enable-debug --enable-depend
PS: if I changed the SQL clause to " select teststruct.regId from teststruct inner join substancename on teststruct.regId = substancename .chemid where teststruct.molfile @('000-502-36.mol ChemDraw08272111072D
11 11 0 0 0 0 0 0 0 0999 V2000 0.3572 0.0000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 0.3572 -0.8250 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 1.0717 -1.2375 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 1.7862 -0.8250 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 1.7862 0.0000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 1.0717 0.4125 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 -0.3572 0.4125 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 -1.0717 0.0000 0.0000 C 0 0 0 0 0 0 0 0 0 0 0 0 -0.3572 1.2375 0.0000 N 0 0 0 0 0 0 0 0 0 0 0 0 -1.7862 0.4125 0.0000 O 0 0 0 0 0 0 0 0 0 0 0 0 -1.0717 -0.8250 0.0000 O 0 0 0 0 0 0 0 0 0 0 0 0 1 2 2 0 2 3 1 0 3 4 2 0 4 5 1 0 5 6 2 0 6 1 1 0 1 7 1 0 7 8 1 0 7 9 1 6 8 10 1 0 8 11 2 0 M END ','')::bingo.exact order by substance.chemid", the server collapsed more frequently;
If somebody would like to dig deeper, these message may be useful.