| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | kuznetsovam(at)altlinux(dot)org, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | nickel(at)altlinux(dot)org, egori(at)altlinux(dot)org |
| Subject: | Re: Detect buffer underflow in get_th() |
| Date: | 2024-07-24 15:39:00 |
| Message-ID: | f884009d-4fe1-4e8d-920c-f0f6a5cc9e11@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 24.07.24 11:43, Alexander Kuznetsov wrote:
> Hello everyone,
>
> In src/backend/utils/adt/formatting.c:1516, there is a get_th() function
> utilized to return ST/ND/RD/TH suffixes for simple numbers.
> Upon reviewing its behavior, it appears capable of receiving non-numeric
> inputs (this is verified by a check at formatting.c:1527).
>
> Given that the function can accept non-numeric inputs,
> it is plausible that it could also receive an empty input,
> although a brief examination of its calls did not reveal any such
> instances.
>
> Nevertheless, if the function were to receive an empty input of zero
> length,
> a buffer underflow would occur when attempting to compute *(num + (len -
> 1)), as (len - 1) would result in a negative shift.
> To mitigate this issue, I propose a patch incorporating the
> zero_length_character_string error code, as detailed in the attachment.
If it can't happen in practice, maybe an assertion would be enough?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-07-24 15:39:56 | Re: Support prepared statement invalidation when result types change |
| Previous Message | Joe Conway | 2024-07-24 15:36:21 | Re: Built-in CTYPE provider |