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

Поиск
Список
Период
Сортировка
Искать
От
Kyotaro Horiguchi
Тема
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)
Дата
Msg-id
20220217.145838.1906684009490104469.horikyota.ntt@gmail.com
Ответ на
Список
Дерево обсуждения
[PATCH] Fix out-of-bouds access (src/common/wchar.c) Ranier Vilela <ranier.vf@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Ranier Vilela <ranier.vf@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Julien Rouhaud <rjuju123@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Julien Rouhaud <rjuju123@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Ranier Vilela <ranier.vf@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Daniel Gustafsson <daniel@yesql.se>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Ranier Vilela <ranier.vf@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Daniel Gustafsson <daniel@yesql.se>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Tom Lane <tgl@sss.pgh.pa.us>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Daniel Gustafsson <daniel@yesql.se>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Ranier Vilela <ranier.vf@gmail.com>
Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) Ranier Vilela <ranier.vf@gmail.com>
(Sorry for the broken mail...)

At Wed, 16 Feb 2022 09:29:20 -0300, Ranier Vilela  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 a
complain about that, maybe.

> 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.

I'll dig into that further.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center


В списке pgsql-hackers по дате отправления
От: Kyotaro Horiguchi
Дата:
От: Andrey Borodin
Дата:
FAQ