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

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

On Thu, Feb 17, 2022 at 05:24:58PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 17 Feb 2022 15:50:09 +0800, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote in
> > On Thu, Feb 17, 2022 at 03:51:26PM +0900, Kyotaro Horiguchi wrote:
> > > So, the function doesn't return 63 for all registered names and wrong
> > > names.
> > >
> > > So other possibilities I can think of are..
> > > - Someone had broken pg_encname_tbl[]
> > > - Cosmic ray hit, or ill memory cell.
> > > - Coverity worked wrong way.
> > >
> > > Could you show the workload for the Coverity warning here?
> >
> > The 63 upthread was hypothetical right? pg_encoding_max_length() shouldn't be
>
> I understand that Coverity complaind pg_verify_mbstr_len is fed with
> encoding = 63 by length_in_encoding. I don't know what made Coverity
> think so.

Not sure either. As you said this assumes that pg_char_to_encoding() can
return something higher than _PG_LAST_ENCODING_ and I also fail to see how that
could happen.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-02-17 08:57:49 Re: Assert in pageinspect with NULL pages
Previous Message Daria Lepikhova 2022-02-17 08:46:40 Assert in pageinspect with NULL pages