babelfish-for-postgresql / babelfish_extensions / 28077089988 / 1
77%
BABEL_6_X_DEV: 77%

DEFAULT BRANCH: BABEL_6_X_DEV
Ran
Files 128
Run time 6s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 77.309% (-0.005%) from 77.314%
28077089988.1

push

github

web-flow 
Fix OOB read and harden allocation-size math in MultiLineString varbinary parsing (#4870) (#4876)

Currently, the CLR-binary → PostGIS conversion path for spatial types (reached via `CAST(0x... AS sys.geometry)`) does not fully validate attacker-controllable fields in the serialized MultiLineString/MultiPoint layout. With this change, two such gaps introduced in the MultiLineString support work (#4831) are closed so that malformed input is rejected with a clean conversion error instead of crashing the backend or corrupting downstream processing.

- **What it used to do:** `parse_figures_and_shapes()` accepted a child shape `figure_offset` of `0xFFFFFFFF` for any shape, because the bounds check explicitly exempted that sentinel. The `0xFFFFFFFF` sentinel is only meaningful for *empty* geometries, which take a separate path (`handle_empty_geometry_bytea`, selected when
  `npoints == 0`) and never reach this code. A crafted *non-empty* MultiLineString/MultiPoint with a child `figure_offset = 0xFFFFFFFF` therefore passed validation, and `get_child_info()` later used that value to index the `figures[]` array — an out-of-bounds read far past the allocated buffer, crashing the backend. Separately, `handle_multi_to_postgis()` accumulated the output WKB size in a `uint32_t` and only checked each child against `MaxAllocSize`, never the running total.
- **What it does now:** non-empty multi-geometry child shapes must reference a valid in-range figure; any out-of-range `figure_offset` (including the `0xFFFFFFFF` sentinel) is rejected with the standard varbinary-conversion error before it can be dereferenced. The output-size accumulator now uses a `uint64_t` and is checked against `MaxAllocSize` on every iteration, consistent with the existing per-child check in `calculate_child_wkb_size()`.
- **Why:** the `figure_offset` gap is an out-of-bounds read reachable by any authenticated user that crashes the backend (denial of service). The accumulator change is defense... (continued)

55749 of 72112 relevant lines covered (77.31%)

594409.34 hits per line

Source Files on job 28077089988.1