| From: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
|---|---|
| To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, andrew(at)dunslane(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Residual cleanups for tied objects in PL/Perl |
| Date: | 2026-09-30 18:35:10 |
| Message-ID: | CAB8bMisFu7xfZ_4Rh8Yvq6JHhhKuTPLT99AzDfoyTQ8j4KRauw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
ср, 30 сент. 2026 г. в 21:18, Kirill Reshke <reshkekirill(at)gmail(dot)com>:
> On Wed, 19 Aug 2026 at 23:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > I wrote:
> > > I plan to study your patch more closely tomorrow.
> >
> > Pushed after some mostly-cosmetic fiddling, and I incorporated
> > your test cases from upthread. Thanks for working on this!
> >
> > regards, tom lane
> >
>
>
> HI!
> I was running some random fuzzing recently, and I bumped into another
> related issue. Not sure if this is worth fixing, but maybe it is worth
> reporting. No modules required. A trusted plperl function that returns
> a SETOF result as a tied array whose class does not implement
> FETCHSIZE exits. Fails on current master 1f7013fe089 and 19beta4
> b73d13c32c8.
>
>
> CREATE EXTENSION plperl;
>
> CREATE OR REPLACE FUNCTION pl_mf_tr() RETURNS SETOF int LANGUAGE plperl AS
> $$
> package MF;
> sub TIEARRAY { my $c = shift; bless { }, $c }
> sub FETCH { 42 }
> my @a; tie @a, 'MF';
> return \(at)a;
> $$;
>
> SELECT count(*) FROM pl_mf_tr();
>
>
> Breakpoint 1, __GI_exit (status=255) at ./stdlib/exit.c:137
> warning: 137 ./stdlib/exit.c: No such file or directory
> (gdb) bt
> #0 __GI_exit (status=255) at ./stdlib/exit.c:137
> #1 0x0000713157470bef in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #2 0x0000713157470cc6 in Perl_my_failure_exit () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #3 0x000071315756cef3 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #4 0x00007131574fd71b in Perl_croak_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #5 0x00007131574fd72d in Perl_die_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #6 0x000071315757b0b0 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #7 0x000071315751ec7e in Perl_runops_standard () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #8 0x00007131574691af in Perl_call_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #9 0x00007131574fa38a in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #10 0x00007131574fd763 in Perl_vcroak () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #11 0x00007131574fe2ea in Perl_croak () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #12 0x0000713157478eff in Perl_gv_fetchmethod_pvn_flags () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #13 0x00007131574790fc in Perl_gv_fetchmethod_sv_flags () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #14 0x000071315752f7a7 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #15 0x000071315751ec7e in Perl_runops_standard () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #16 0x00007131574691af in Perl_call_sv () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #17 0x0000713157504368 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #18 0x0000713157504733 in ?? () from /lib/x86_64-linux-gnu/libperl.so.5.38
> #19 0x00007131575019f8 in Perl_mg_size () from
> /lib/x86_64-linux-gnu/libperl.so.5.38
> #20 0x00007131643797ce in Perl_av_count (av=0x5d7778b83290,
> my_perl=0x5d7778b49cf0) at
> /usr/lib/x86_64-linux-gnu/perl/5.38/CORE/inline.h:61
> #21 Perl_av_count (av=0x5d7778b83290, my_perl=0x5d7778b49cf0) at
> /usr/lib/x86_64-linux-gnu/perl/5.38/CORE/inline.h:56
> #22 plperl_func_handler (fcinfo=<optimized out>) at plperl.c:2461
> #23 plperl_call_handler (fcinfo=0x5d7778c26630) at plperl.c:1864
>
>
>
> --
> Best regards,
> Kirill Reshke
>
Hi, Kirill!
I, Tom, and the security team are aware of it. I found this a while ago. I
proposed a patch on how to close this issue (the sec team may have their
own solution). I think the issue will be resolved in the near future.
--
Regards,
Rachitskiy Andrey
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Matheus Alcantara | 2026-09-30 18:27:10 | Re: postgres_fdw: transaction mode inheritance corner cases |