Re: BUG #19601: Vuln45: Unbounded recursion via self-retying Perl scalar in bool_plperl's SvTRUE call causes backend

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I can't get excited about this. A plperl user who wishes to cause
> recursion to stack overflow can do so far more simply than what is
> proposed here: just write an indefinitely-recursive Perl function
> and call it. That recursion will be totally inside libperl, so
> we can do nothing about it. The same holds for every other PL
> that exposes a general-purpose programming language.
>
> I certainly wouldn't add the amount of code you propose here to close
> off just one route to that, even if I trusted the patch which I don't.
> (It seems far too much in-bed with details of libperl's innards, and
> hence likely to fail on other Perl versions than what you tested.)

Fair enough.

This is not an attempt to argue for committing that patch.
It was called a prototype in the earlier mail, and it was explicitly noted
that this might not be the right approach.
The main intention was only to demonstrate that this particular path can be
intercepted by reaching into Perl's leave/op mechanics.

You have already explained to me before that this class of failure is not
really a PostgreSQL problem.
Thank you again for that — I should have applied the same reasoning here
sooner.

The report caught attention because it pointed at bool_plperl's SvTRUE() as
the bug.

вт, 4 авг. 2026 г. в 03:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> writes:
> > Thanks for the report. I can reproduce the SIGSEGV on current master
> > (with --with-perl).
>
> I can't get excited about this. A plperl user who wishes to cause
> recursion to stack overflow can do so far more simply than what is
> proposed here: just write an indefinitely-recursive Perl function
> and call it. That recursion will be totally inside libperl, so
> we can do nothing about it. The same holds for every other PL
> that exposes a general-purpose programming language.
>
> I certainly wouldn't add the amount of code you propose here to close
> off just one route to that, even if I trusted the patch which I don't.
> (It seems far too much in-bed with details of libperl's innards, and
> hence likely to fail on other Perl versions than what you tested.)
>
> regards, tom lane
>

--
Regards,
Rachitskiy Andrey