BUG #18533: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup - Mailing list pgsql-bugs
From | PG Bug reporting form |
---|---|
Subject | BUG #18533: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup |
Date | |
Msg-id | 18533-7c9fe722cf1351f6@postgresql.org Whole thread Raw |
Responses |
Re: BUG #18533: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup
|
List | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 18533 Logged by: ji xiaohang Email address: 1165125080@qq.com PostgreSQL version: 16.3 Operating system: centos 7 Description: pg_basebackup uses out-of-bounds memory and a segment error occurs during backup Run the following command to back up the pg11 database using the pg_basebackup backup tool of the pg16 version: pg_basebackup -h 127.0.0.1 -p 56100 -U Backup -F tar -X f -z -c fast -P -v -D - > base.tar.gz The segmentation fault does not recur after I run commands. It seems that this problem recurs only in my service invoking scenario. If the backup content is BBFLOWER_MEMBER_TRAILER, the coredump stack information is as follows: #0 __memmove_evex_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:476 #1 0x00007f0d8b928ef1 in memcpy (__len=388, __src=0x5625f0fcffa4, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:29 #2 gz_write (state=0x5625f0f862d0, buf=0x5625f0fcffa4, len=388) at gzwrite.c:213 #3 0x00007f0d8b929034 in gz_write (len=<optimized out>, buf=<optimized out>, state=<optimized out>) at gzwrite.c:270 #4 gzwrite (file=<optimized out>, buf=<optimized out>, len=<optimized out>) at gzwrite.c:270 #5 0x00005625efaa4570 in bbstreamer_gzip_writer_content (streamer=0x5625f0f85170, member=0x5625f0f87db0, data=0x5625f0fcffa4 "", len=388, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer_gzip.c:138 #6 0x00005625efaa57d4 in bbstreamer_content (streamer=0x5625f0f85170, member=0x5625f0f87db0, data=0x5625f0fcffa4 "", len=388, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer.h:145 #7 0x00005625efaa64ff in bbstreamer_tar_archiver_content (streamer=0x5625f0f863c0, member=0x5625f0f87db0, data=0x5625f0fcffa4 "", len=388, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer_tar.c:508 #8 0x00005625efaa57d4 in bbstreamer_content (streamer=0x5625f0f863c0, member=0x5625f0f87db0, data=0x5625f0fcffa4 "", len=388, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer.h:145 #9 0x00005625efaa5c00 in bbstreamer_tar_parser_content (streamer=0x5625f0f87d80, member=0x0, data=0x5625f0fcffa4 "", len=0, context=BBSTREAMER_UNKNOWN) at bbstreamer_tar.c:228 #10 0x00005625efa9dc85 in bbstreamer_content (streamer=0x5625f0f87d80, member=0x0, data=0x5625f0fcfe20 "", len=388, context=BBSTREAMER_UNKNOWN) at bbstreamer.h:145 #11 0x00005625efaa127d in ReceiveTarCopyChunk (r=388, copybuf=0x5625f0fcfe20 "", callback_data=0x7ffe9ceffef0) at pg_basebackup.c:1759 #12 0x00005625efa9fe1f in ReceiveCopyData (conn=0x5625f0f70b10, callback=0x5625efaa123c <ReceiveTarCopyChunk>, callback_data=0x7ffe9ceffef0) at pg_basebackup.c:1102 #13 0x00005625efaa1115 in ReceiveTarFile (conn=0x5625f0f70b10, archive_name=0x7ffe9cf00460 "base.tar", spclocation=0x0, tablespacenum=true, compress=0x7ffe9cf008e0) at pg_basebackup.c:1708 #14 0x00005625efaa2481 in BaseBackup (compression_algorithm=0x5625f0f6f5f0 "gzip", compression_detail=0x5625f0f6f610 "2", compressloc=COMPRESS_LOCATION_CLIENT, client_compress=0x7ffe9cf008e0) at pg_basebackup.c:2177 #15 0x00005625efaa3ad6 in main (argc=17, argv=0x7ffe9cf00a48) at pg_basebackup.c:2900 According to the stack analysis, the address of the copybuf (or data) received from the server is changed in the bbstreamer_tar_archiver_content function. The data address is moved forward by 388 bytes, that is, the length of the variable len. After analysis, the bbstreamer_buffer_until command is executed, causing the data address to change. In this case, the data pointer points to the end of the available address, and len = 0. However, in bbstreamer_tar_archiver_content and bbstreamer_gzip_writer_content, the value of len is restored to 388. When gz_write is finally invoked, memory overwriting occurs and an error occurs. In addition, when the pg16.3 server is backed up, memory overwriting also occurs. but no segmentation fault. #0 bbstreamer_gzip_writer_content (streamer=0x5555555aa830, member=0x5555555ab8c0, data=0x5555555aa495 "", len=260, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer_gzip.c:132 #1 0x0000555555560631 in bbstreamer_content (streamer=0x5555555aa830, member=0x5555555ab8c0, data=0x5555555aa495 "", len=260, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer.h:145 #2 0x0000555555561279 in bbstreamer_tar_archiver_content (streamer=0x5555555aaf20, member=0x5555555ab8c0, data=0x5555555aa495 "", len=260, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer_tar.c:508 #3 0x0000555555560631 in bbstreamer_content (streamer=0x5555555aaf20, member=0x5555555ab8c0, data=0x5555555aa495 "", len=260, context=BBSTREAMER_MEMBER_TRAILER) at bbstreamer.h:145 #4 0x0000555555560a53 in bbstreamer_tar_parser_content (streamer=0x5555555ab890, member=0x0, data=0x5555555aa495 "", len=0, context=BBSTREAMER_UNKNOWN) at bbstreamer_tar.c:228 #5 0x0000555555558c84 in bbstreamer_content (streamer=0x5555555ab890, member=0x0, data=0x5555555aa391 "", len=260, context=BBSTREAMER_UNKNOWN) at bbstreamer.h:145 #6 0x000055555555bbed in ReceiveArchiveStreamChunk (r=261, copybuf=0x5555555aa390 "d", callback_data=0x7fffffffd420) at pg_basebackup.c:1528 #7 0x000055555555ad34 in ReceiveCopyData (conn=0x555555596660, callback=0x55555555b8af <ReceiveArchiveStreamChunk>, callback_data=0x7fffffffd420) at pg_basebackup.c:1102 #8 0x000055555555b7cd in ReceiveArchiveStream (conn=0x555555596660, compress=0x7fffffffe220) at pg_basebackup.c:1379 #9 0x000055555555d1ff in BaseBackup (compression_algorithm=0x555555582fed "gzip", compression_detail=0x0, compressloc=COMPRESS_LOCATION_CLIENT, client_compress=0x7fffffffe220) at pg_basebackup.c:2147 #10 0x000055555555e94a in main (argc=19, argv=0x7fffffffe338) at pg_basebackup.c:2900 Do I think we should remove the bbstreamer_buffer_until call in the bbstreamer_tar_parser_content function in the scenario of BBFLOWER_MEMBER_TRAILER? / * * If we're expecting an archive member trailer, accumulate * the expected number of padding bytes before sending * anything onward. * / if (!bbstreamer_buffer_until(streamer, &data, &len, mystreamer->pad_bytes_expected)) return;
pgsql-bugs by date: