Skip site navigation (1) Skip section navigation (2)

BUG #4625: ECPG: Memory allocation for binary data is wrong

From: "Tomislav Bodor" <tbodor(at)yahoo(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #4625: ECPG: Memory allocation for binary data is wrong
Date: 2009-01-23 09:25:31
Message-ID: 200901230925.n0N9PVvJ063286@wwwmaster.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-bugs
The following bug has been logged online:

Bug reference:      4625
Logged by:          Tomislav Bodor
Email address:      tbodor(at)yahoo(dot)com
PostgreSQL version: 8.3.5
Operating system:   Linux (Ubuntu 8.10)
Description:        ECPG: Memory allocation for binary data is wrong
Details: 

When using binary cursor to fetch contents of a bytea column into a variable
set to NULL, the memory allocation relies on strlen to determine the amount
of memory to allocate. If the data contains zeros, the memory allocated is
too little to store the data.

Something like this:

EXEC SQL BEGIN DECLARE SECTION;
unsigned char* data = NULL;
unsigned char* data_in = "\\001\\000\\002\\003\\004";
EXEC SQL END DECLARE SECTION;


EXEC SQL CREATE TABLE test (
    id serial primary key,
    data bytea
);

EXEC SQL INSERT INTO test (data) VALUES (:data_in);

EXEC SQL DECLARE b BINARY CURSOR FOR
        SELECT data FROM test WHERE id = 1;

EXEC SQL OPEN b;
EXEC SQL ALLOCATE DESCRIPTOR d;
EXEC SQL FETCH FROM b INTO DESCRIPTOR d;

EXEC SQL GET DESCRIPTOR d VALUE 1 :data = DATA;

EXEC SQL DEALLOCATE d;
EXEC SQL CLOSE b;


Note the byte 1 in the data_in array is zero. Now, the memory for data
variable is allocated in ecpg_store_result (ecpg/ecpglib/descriptor.c), but
it relies on strlen there and allocates only 2 bytes (strlen == 1, plus 1
for zero termination). Too little to copy 5 bytes of data into it. Hard to
demonstrate the resulting memory corruption with a simple example, but
valgrind will show it for the example above.

Workaround: pre-allocate the memory based on the RETURNED_OCTET_LENGTH field
in the descriptor.


Regards,
Tomislav

Responses

pgsql-bugs by date

Next:From: Ruslan A DautkhanovDate: 2009-01-23 12:53:37
Subject: make of 8.3.5 failed on Linux
Previous:From: AlexanderDate: 2009-01-23 09:15:48
Subject: BUG #4624: pg_restore

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group