develooper Front page | perl.perl5.changes | Postings from October 2021

[Perl/perl5] 638b4d: hv_delete_common() must not call GvAV() on anon-GV

From:
Nicholas Clark via perl5-changes
Date:
October 20, 2021 18:54
Subject:
[Perl/perl5] 638b4d: hv_delete_common() must not call GvAV() on anon-GV
Message ID:
Perl/perl5/push/refs/heads/blead/17ff34-a31d03@github.com
  Branch: refs/heads/blead
  Home:   https://github.com/Perl/perl5
  Commit: 638b4d9051af3a8aa432795a1f33508001c1754e
      https://github.com/Perl/perl5/commit/638b4d9051af3a8aa432795a1f33508001c1754e
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-20 (Wed, 20 Oct 2021)

  Changed paths:
    M hv.c
    M t/op/gv.t

  Log Message:
  -----------
  hv_delete_common() must not call GvAV() on a non-GV

hv_delete_common() must update isa magic stash records when *ISA is deleted
(see commit 6146d9e1c87d449f)

However, it's only valid to use the macro GvAV() on an SV that is a GV.
Previously the code was not checking this, hence if someone deliberately
manipulated the symbol table to first store something other than a typeglob,
and then delete that entry from the symbol table, then (at best) an
assertion would fail, at worst illegal memory accesses.

Do this by moving the check for `SvTYPE(sv) == SVt_PVGV` up to the if() that
governs both code blocks.

Note that you could only trigger this bug by running code that manipulates
symbol tables directly. Compilation of Perl code would not hit it, nor could
user-controlled data in executing Perl programs, unless the programs both
contain code to manipulate symbol tables, and permit unvalidated user data
to reach those code paths.

(Such programs are likely insecure already, as their control flow can be
subverted by user controlled data without requiring any interpreter bugs.)


  Commit: 7c4cc0343c223680358a798ea6826c8c3a710db3
      https://github.com/Perl/perl5/commit/7c4cc0343c223680358a798ea6826c8c3a710db3
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-20 (Wed, 20 Oct 2021)

  Changed paths:
    M hv.c

  Log Message:
  -----------
  Perl_newHVhv() did not correctly copy hashes with non-shared keys

It created a hash built with non-shared keys, but left the "shared keys"
flag set on the hash.

This hasn't been spotted in 20 years, which shows just how much we use
hashes with unshared keys.


  Commit: 33042aafe7427f88db58e555390c82dd25ef9a28
      https://github.com/Perl/perl5/commit/33042aafe7427f88db58e555390c82dd25ef9a28
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-20 (Wed, 20 Oct 2021)

  Changed paths:
    M ext/Devel-Peek/t/Peek.t
    M ext/XS-APItest/APItest.xs
    M hv.c
    M t/op/tr.t

  Log Message:
  -----------
  Fix the build and tests when NODEFAULT_SHAREKEYS is defined

Defining this macro causes newHV() to create hashes without shared hash key
scalars. The default is that hashes are created with shared hash keys.


  Commit: a31d0367bbf1e97bab6eece95b47ca513e1834a6
      https://github.com/Perl/perl5/commit/a31d0367bbf1e97bab6eece95b47ca513e1834a6
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-20 (Wed, 20 Oct 2021)

  Changed paths:
    M hv.c

  Log Message:
  -----------
  Perl_newHVhv should use share_hek_hek() instead of share_hek_flags()

share_hek_hek() manipulates the shared HEK's reference count directly,
without needing to find it in the shared string table. It was added after
Perl_newHVhv() was implemented, and no-one noticed that it could be used
there.


Compare: https://github.com/Perl/perl5/compare/17ff3452b77c...a31d0367bbf1



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About