Content-Type: multipart/mixed; boundary="------------DvX5ohY9koIVfnsypJZbgneM"
Message-ID: <01fc0593-e31e-463d-902c-dd43174acee2@oopacity.net>
Date: Wed, 18 Oct 2023 16:21:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: fr, en-US
From: Flavien GUEDEZ <flav.pg@oopacity.net>
To: pgsql-bugs@lists.postgresql.org
Subject: Insufficient memory access checks in pglz_decompress
Archived-At: 
 <https://www.postgresql.org/message-id/01fc0593-e31e-463d-902c-dd43174acee2%40oopacity.net>
Precedence: bulk

This is a multi-part message in MIME format.
--------------DvX5ohY9koIVfnsypJZbgneM
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

After some investigations about very corrupted toast data in one 
postgres instance, I found that the pglz_decompress function (in 
common/pg_lzcompress.c) does not check correctly where it copies data 
from using memcpy(), which could result in segfault.
In this function, there are other checks to ensure that we do not copy 
after the destination end, but not if we copy data from "before the 
beginning".

Apologize, I am not a C developer and I am not used to submitting patches.
Though I have tried and attached kind of PoC with a relatively random 
corrupted payload (it was beginning with those bytes in my storage for 
obscure reasons).
Also attached a simple patch of what could be done just before the 
memcpy calls.

Regards,

Flavien

--------------DvX5ohY9koIVfnsypJZbgneM
Content-Type: text/x-patch; charset=UTF-8; name="check_for_corrupted.patch"
Content-Disposition: attachment; filename="check_for_corrupted.patch"
Content-Transfer-Encoding: base64

LS0tIGEvc3JjL2NvbW1vbi9wZ19semNvbXByZXNzLmMJMjAyMy0xMC0xOCAxMjozNDozMC42
MTYwMDAwMDAgKzAwMDAKKysrIGIvc3JjL2NvbW1vbi9wZ19semNvbXByZXNzLmMJMjAyMy0x
MC0xOCAxMjo0ODowOS45NjgwMDAwMDAgKzAwMDAKQEAgLTc2MSw3ICs3NjEsMTIgQEAKIAkJ
CQkJLyoKIAkJCQkJICogV2UgY2FuIHNhZmVseSBjb3B5ICJvZmYiIGJ5dGVzIHNpbmNlIHRo
YXQgY2xlYXJseQogCQkJCQkgKiByZXN1bHRzIGluIG5vbi1vdmVybGFwcGluZyBzb3VyY2Ug
YW5kIGRlc3RpbmF0aW9uLgorCQkJCQkgKiBDaGVjayBmb3IgY29ycnVwdCBkYXRhOiBpZiB3
ZSBmYWxsIGJlZm9yZSB0aGUgYmVnaW5uaW5nIG9mIHRoZQorCQkJCQkgKiBkZXN0aW5hdGlv
biwgd2UgaGF2ZSBwcm9ibGVtcy4KIAkJCQkJICovCisJCQkJCWlmIChkcCAtIG9mZiA8IGRl
c3QpIHsKKwkJCQkJCXJldHVybiAtMTsKKwkJCQkJfQogCQkJCQltZW1jcHkoZHAsIGRwIC0g
b2ZmLCBvZmYpOwogCQkJCQlsZW4gLT0gb2ZmOwogCQkJCQlkcCArPSBvZmY7CkBAIC03OTIs
NiArNzk3LDEzIEBACiAJCQkJCSAqLwogCQkJCQlvZmYgKz0gb2ZmOwogCQkJCX0KKwkJCQkv
KgorCQkJCSAqIENoZWNrIGZvciBjb3JydXB0IGRhdGE6IGlmIHdlIGZhbGwgYmVmb3JlIHRo
ZSBiZWdpbm5pbmcgb2YgdGhlCisJCQkJICogZGVzdGluYXRpb24sIHdlIGhhdmUgcHJvYmxl
bXMuCisJCQkJICovCisJCQkJaWYgKGRwIC0gb2ZmIDwgZGVzdCkgeworCQkJCQlyZXR1cm4g
LTE7CisJCQkJfQogCQkJCW1lbWNweShkcCwgZHAgLSBvZmYsIGxlbik7CiAJCQkJZHAgKz0g
bGVuOwogCQkJfQoK
--------------DvX5ohY9koIVfnsypJZbgneM
Content-Type: text/x-csrc; charset=UTF-8; name="poc.c"
Content-Disposition: attachment; filename="poc.c"
Content-Transfer-Encoding: base64

I2luY2x1ZGUgPGN0eXBlLmg+CiNpbmNsdWRlIDxzdGRpby5oPgoKI2luY2x1ZGUgInBvc3Rn
cmVzLmgiCgppbnQKbWFpbihpbnQgYXJndiwgY2hhciAqKmFyZ2MpCnsKCWNoYXIgKmNvcnJ1
cHRlZF9jb21wcmVzc2VkX3BheWxvYWQgPSAiXHgyMVx4MUNceDQ0XHgzNlx4MzhceDU2XHg0
MFx4MzdcMCI7CglpbnQgY29ycnVwdGVkX2NvbXByZXNzZWRfcGF5bG9hZF9zaXplID0gc3Ry
bGVuKGNvcnJ1cHRlZF9jb21wcmVzc2VkX3BheWxvYWQpOwoJaW50IGRlY29tcHJlc3NfdG1w
X2J1ZmZfc2l6ZSA9IDEwMjQ7IC8vIHZlcnkgYXJiaXRyYXJ5CgoJY2hhciAqZGVjb21wcmVz
c190bXBfYnVmZiA9IG1hbGxvYyhkZWNvbXByZXNzX3RtcF9idWZmX3NpemUqc2l6ZW9mKGNo
YXIpKTsKCglpbnQgZGVjb21wcmVzc19yZXQ7CglkZWNvbXByZXNzX3JldCA9IHBnbHpfZGVj
b21wcmVzcyhjb3JydXB0ZWRfY29tcHJlc3NlZF9wYXlsb2FkLCBjb3JydXB0ZWRfY29tcHJl
c3NlZF9wYXlsb2FkX3NpemUsCgkJZGVjb21wcmVzc190bXBfYnVmZiwgZGVjb21wcmVzc190
bXBfYnVmZl9zaXplLCB0cnVlKTsKCglpZihkZWNvbXByZXNzX3JldCA9PSAtMSkgewoJCXBy
aW50ZigiZGF0YSBpcyBjb3JydXB0ZWRcbiIpOwoJfQoKCWZyZWUoZGVjb21wcmVzc190bXBf
YnVmZik7CgkKCXJldHVybiAwOwp9Cgo=

--------------DvX5ohY9koIVfnsypJZbgneM--