Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: ranier(dot)vf(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)
Date: 2022-02-17 05:56:37
Message-ID: 20220217.145637.1058044688692180437.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 16 Feb 2022 09:29:20 -0300, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote in
> > > ]
> > > 633 retval = pg_verify_mbstr_len(src_encoding, src_str, len,
> > false);
> > > 634
> > >
> > > Trivial patch attached.
> >
> > Mmm? If the assert doesn't work, there should be inconcsistency
> > between pg_enc and pg_wchar_table. But AFAICS they are consistent.
> >
> The consistency is between pg_encname_tbl and pc_enc, and AFAICS are
> consistent.

..Yeah, right.

> > The patch:
> > pg_encoding_max_length(int encoding)
> > {
> > - Assert(PG_VALID_ENCODING(encoding));
> > -
> > - return pg_wchar_table[encoding].maxmblen;
> > + if (PG_VALID_ENCODING(encoding))
> > + return pg_wchar_table[encoding].maxmblen;
> > + else
> > + return -1;
> >
> > Returning -1 for invalid encoding is, I think, flat wrong.
> >
> Ok, if -1 is wrong, what should the value of return if
> somebody calling this function like:
> pg_encoding_max_length(63);

Should result in assertion failure, I think. If that fails, the
caller side is anyhow broken. On the other hand we haven't had I'll
dig into that further.

> Of course, with patch applied, because with original code
> has memory corruption, if built and run without DEBUG.

So we don't assume corruption in production build. It should be
logically guaranteed.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-02-17 05:58:38 Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)
Previous Message Kyotaro Horiguchi 2022-02-17 05:16:47 Re: BufferAlloc: don't take two simultaneous locks