Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum - Mailing list pgsql-bugs

From Andrey M. Borodin
Subject Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
Date
Msg-id 0FDE2089-D306-4CBB-AD1F-EC4B419E3B33@yandex-team.ru
Whole thread Raw
In response to [BUG] false positive in bt_index_check in case of short 4B varlena datum  (Michael Zhilin <m.zhilin@postgrespro.ru>)
Responses Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs

> On 14 Dec 2023, at 21:18, Michael Zhilin <m.zhilin@postgrespro.ru> wrote:

I've checked that:
* bug is reproduced by the test in the patch
* bug is fixed by the patch
* fix seems idiomatic, similar to nearby code

Patch needed a rebase, so please find attached rebased version. I did not change anything.

I see that using a temp file in PG_ABS_SRCDIR is common approach. But still I want to ask, maybe can we develop some
cleverway to reproduce the bug without external file? 
Also, maybe nearby code would be slightly more readable, if normalized[i] was a local variable.
And one last question about the line:
char *data = palloc(len);
what if data is somehow corrupted here... are there enough sanity checks that we won't palloc(-1) or something like
that?
Won't we memcpy() from some other memory when len is bogus?

Besides this paranoid questions, I think that this patch is ready for committer.

Thanks!


Best regards, Andrey Borodin.



Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18276: Heap-buffer-overflow triggered in src/backend/utils/adt/datum.c:163
Next
From: Tom Lane
Date:
Subject: Re: BUG #18274: Error 'invalid XML content'