On Sat, Nov 12, 2022 at 1:47 PM Andrey Borodin <amborodi...@gmail.com> wrote: > > I've tried the patch, it works as advertised.
While testing patch some more I observe unpleasant segfaults: #26 0x00007fecafa1e058 in __memcpy_ssse3_back () from target:/lib64/libc.so.6 #27 0x000000000b08fda2 in lz4_decompress (d_stream=0x18cf82a0, src=0x7feae4fa505d, src_size=92, src_processed=0x7ffff9f4fdf8, dst=0x18b01f80, dst_size=8192, dst_processed=0x7ffff9f4fe60) #28 0x000000000b090624 in zs_read (zs=0x18cdfbf0, src=0x7feae4fa505d, src_size=92, src_processed=0x7ffff9f4fdf8, dst=0x18b01f80, dst_size=8192, dst_processed=0x7ffff9f4fe60) #29 0x000000000b08eb8f in zpq_read_compressed_message (zpq=0x7feae4fa5010, dst=0x18b01f80 "Q", dst_len=8192, dst_processed=0x7ffff9f4fe60) #30 0x000000000b08f1a9 in zpq_read (zpq=0x7feae4fa5010, dst=0x18b01f80, dst_size=8192, noblock=false) (gdb) select-frame 27 (gdb) info locals ds = 0x18cf82a0 decPtr = 0x18cf8aec "" decBytes = -87 This is the buffer overrun by decompression. I think the receive buffer must be twice bigger than the send buffer to accommodate such messages. Also this portion of lz4_decompress() Assert(decBytes > 0); must actually be a real check and elog(ERROR,). Because clients can intentionally compose CompressedData to blow up a server. Best regards, Andrey Borodin.