Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum

From: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>
To: Michael Zhilin <m(dot)zhilin(at)postgrespro(dot)ru>
Cc: pgsql-bugs(at)postgresql(dot)org, y sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Alexander Lakhin <exclusion(at)gmail(dot)com>
Subject: Re: [BUG] false positive in bt_index_check in case of short 4B varlena datum
Date: 2024-01-07 18:04:35
Message-ID: 0FDE2089-D306-4CBB-AD1F-EC4B419E3B33@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 14 Dec 2023, at 21:18, Michael Zhilin <m(dot)zhilin(at)postgrespro(dot)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 clever way 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 Content-Type Size
v1rebased-0001-contrib-amcheck-must-support-different-hea.patch application/octet-stream 6.2 KB
unknown_filename text/plain 2 bytes

In response to

Responses

Browse pgsql-bugs by date

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