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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: rjuju123(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:24:58
Message-ID: 20220217.172458.760758446159742763.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> called with user-dependent data (unlike pg_encoding_max_length_sql()), so I
> also don't see any value spending cycles in release builds. The error should
> only happen with bogus code, and assert builds are there to avoid that, or
> corrupted memory and in that case we can't make any promise.

Well, It's more or less what I wanted to say. Thanks.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daria Lepikhova 2022-02-17 08:46:40 Assert in pageinspect with NULL pages
Previous Message Kyotaro Horiguchi 2022-02-17 08:14:05 Re: [Proposal] Add foreign-server health checks infrastructure