develooper Front page | perl.perl5.porters | Postings from September 2016

Re: [perl #129267] Possible string overrun with invalid len in gv.c

Thread Previous | Thread Next
September 13, 2016 21:30
Re: [perl #129267] Possible string overrun with invalid len in gv.c
Message ID:
On 13 September 2016 at 22:00, Todd Rinaldo via RT
<> wrote:
> On Tue Sep 13 12:14:27 2016, demerphq wrote:
>> On 13 September 2016 at 21:06, Todd Rinaldo via RT
>> <> wrote:
>> > On Tue Sep 13 12:01:23 2016, demerphq wrote:
>> >>
>> >> We can and should audit for similar patterns, but my gut feeling is
>> >> that this code is pretty unusual, as it is trying to extract the
>> >> function part of a fully qualified name.
>> >>
>> >
>> > S_parse_gv_stash_name is making a similar look ahead mistake with
>> > name_cursor[1]. That looks messier to fix but it should probably be
>> > another case or a committer should just go through and make the
>> > corrections sans perlbug?
>> A quick look didnt reveal to me any issues here. If you look at the
>> way it uses name_em1 and name_end it looks fine. Can you point me more
>> closely at the code you suspect?
> Yep. Apologies. I pulled the trigger too quick on that one.

Yeah, well so did I with that premature push. :-)

Anyway, I repushed my changes:

cfb7367 fix #129267: rework gv_fetchmethod_pvn_flags separator parsing
e2cace1 clean up gv_fetchmethod_pvn_flags: rename nsplit to last_separator
d5ea0ef clean up gv_fetchmethod_pvn_flags: move origname init to function start
65308f8 clean up gv_fetchmethod_pvn_flags: introduce name_end

I think the code is much easier to understand now.

FC, I didnt really see a way to test for a string overrun via
XS::APItest, maybe I didnt try hard enough tho. Can you think of

(I think this ticket can be closed tho.)


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About