psql crashes on encoding mismatch

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: psql crashes on encoding mismatch
Date: 2011-01-12 16:24:57
Message-ID: AANLkTinoSnDVCFtSRX=3avUyXdg9JHf0WZf413dVrhxw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I found a crash case (assertion failure) when runing psql -f
utf8_encoded_script.sql against client_encoding = shift_jis in
postgresql.conf. Though encoding mismatch is obviously user's fault, a
crash doesn't explain anything to him.

The thing is, prepare_buffer() in psqlscan.l assumes PQmblen() always
returns the appropriate length, but it actually isn't. newtxt can be
overflowed on those cases into the following 2 byte NULLs, which is
filled in the beginning of prepare_buffer(). It results in that
yy_scan_buffer() returns NULL by design since the input buffer's
following 2 bytes are not NULL. Then,
psql_assert(state->scanbufhandle) in psql_scan() detects bug later.
This bug can be occurred not only in shift_jis but also big5, bgk,
etc. "unsafe" encodings.

The attached is to fix it. Just double check not to pad overflowed
0xff for the input buffer. If you need unit case I'll send it, but the
problem seems clear.

Regards,

--
Hitoshi Harada

Attachment Content-Type Size
psql_encoding_bugfix.patch application/octet-stream 475 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-01-12 16:41:40 Re: Add support for logging the current role
Previous Message Stephen Frost 2011-01-12 16:00:30 Re: Add support for logging the current role