gregfelice commented on PR #2410: URL: https://github.com/apache/age/pull/2410#issuecomment-4763379021
Confirming the vulnerability is real and query-reachable: at `age_tofloatlist` (`agtype.c`, the `AGTV_FLOAT` case), `sprintf(buffer, "%f", float_num)` formats a double's full integer part into a 64-byte stack buffer — `±DBL_MAX` is ~309 integer digits + `.000000` ≈ 317 chars, so `RETURN toFloatList([1.0e308])` overflows it. The `snprintf` + larger buffer fixes the overflow. One suggestion that I think is strictly better than enlarging the buffer, and it also resolves @jrgemignani's "400 is a magic number" point by removing the buffer from that path entirely: The value being formatted is **already** a `float8` (`elem->val.float_value`). The current code formats it with `%f` and re-parses the string back into a float: ```c float_num = elem->val.float_value; sprintf(buffer, "%f", float_num); // %f = 6 fractional digits → lossy string = buffer; float_elem.val.float_value = float8in_internal_null(string, ...); ``` Besides the overflow, `%f` truncates to 6 decimal places, so this round-trip is **lossy** — `toFloatList([0.123456789])` currently returns `0.123457`. Since the value is already a double, the format-and-reparse is unnecessary; assigning directly: ```c float_elem.type = AGTV_FLOAT; float_elem.val.float_value = elem->val.float_value; ``` fixes the stack overflow, the precision loss, and the magic-buffer-size question in one move (no buffer, no `sprintf`/`snprintf`, no re-parse). The `snprintf` conversions in `age_tostringlist` are still worth keeping as defensive hardening (those use bounded `%.*g`/`%ld` formats, so they were never overflow-prone — the 64-byte buffer there is fine). If you'd prefer to keep the minimal critical-hotfix shape (`snprintf` + bigger buffer) and address the precision round-trip separately, that's reasonable too — just flagging that the direct assignment is the smaller and more correct end state. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
