Opened 13 months ago
Closed 12 months ago
#4621 closed defect (fixed)
oss-fuzz: stack overflow in lwcollection_from_wkb_state
Reported by: | komzpa | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 3.1.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=20159
4 lines omitted SCARINESS: 10 (stack-overflow) #0 0x4b5641 in __sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1, 20>::Put(__sanitizer::StackTrace, bool*) /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_stackdepotbase.h:98 #1 0x4b5616 in __sanitizer::StackDepotPut(__sanitizer::StackTrace) /src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_stackdepot.cpp:98:33 #2 0x41df1e in __asan::Allocator::Allocate(unsigned long, unsigned long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /src/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:526:27 #3 0x41d933 in __asan::asan_malloc(unsigned long, __sanitizer::BufferedStackTrace*) /src/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp:892:34 #4 0x49509b in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:146:10 #5 0x503bb6 in lwcollection_construct_empty /src/postgis/liblwgeom/lwcollection.c:101:8 #6 0x510090 in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:674:22 #7 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #8 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #9 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #10 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #11 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #12 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #13 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #14 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #15 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #16 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #17 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #18 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #19 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #20 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #21 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #22 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 #23 0x51012c in lwcollection_from_wkb_state /src/postgis/liblwgeom/lwin_wkb.c:690:10 483 lines omitted
Attachments (1)
Change History (10)
Changed 13 months ago by
Attachment: | clusterfuzz-testcase-minimized-wkb_import_fuzzer-5737413385388032.fuzz added |
---|
comment:1 Changed 13 months ago by
comment:2 Changed 13 months ago by
A simpler repro:
/* OSS-FUZZ: https://trac.osgeo.org/postgis/ticket/4621 */ uint32_t big_size = 20000000; uint8_t *wkb5 = lwalloc(big_size); memset(wkb5, 0x01, big_size); g = lwgeom_from_wkb(wkb5, big_size, LW_PARSER_CHECK_NONE); lwgeom_free(g); lwfree(wkb5);
I think we should put a limit to the recursive calls that depend on user input, but I'm not sure what that would be. I'd say that if you have 1024 chained collection you are just trying to break things so we could discard it.
comment:3 Changed 13 months ago by
Bison (which handles WKT) uses YYINITDEPTH 200, so I'll set 200 for WKB too.
comment:4 Changed 13 months ago by
PR in https://github.com/postgis/postgis/pull/536
I haven't checked, but I'd say all version are affected.
Note: See
TracTickets for help on using
tickets.
I'm not sure how to introduce this test without adding the 1M file to the repo, but the issue is with the recursion in lwgeom_from_wkb_state when you have an extremely deep collection (a collection of a collection of a collection...).
In my PC this crashes once it reaches 261962 (!!!) calls: