heap-buffer-overflow in S_do_trans_invmap #17654
Labels
Milestone
Comments
|
This looks like another expression of the same problem as in #17643, that max_expansion is not not calculated for source characters beyond the number of destination characters. |
khwilliamson
added a commit
that referenced
this issue
Apr 1, 2020
A tr/// can be done in-place if the target string doesn't contain a character whose transliterated representation is longer than the original. Otherwise, writing the new value would destroy the next character we need to read. In general, we can't know if a particular string contains such a character without keeping a list of the problematic characters, and scanning it ahead of time for occurrences of those. Instead, we determine at compilation time if, for a given transliteration, if there exists any possible target string that could have an overwriting problem. If none exist, we edit in place. Otherwise, we first make a copy. Prior to this commit, the code failed to account for the case where the rhs is shorter than the left, so that any unmatched lhs characters map to the final rhs one. The reason the code didn't consider this is that I didn't think of this possibility when writing it. This fixes #17654 and #17643
khwilliamson
added a commit
that referenced
this issue
Apr 1, 2020
A tr/// can be done in-place if the target string doesn't contain a character whose transliterated representation is longer than the original. Otherwise, writing the new value would destroy the next character we need to read. In general, we can't know if a particular string contains such a character without keeping a list of the problematic characters, and scanning it ahead of time for occurrences of those. Instead, we determine at compilation time if, for a given transliteration, if there exists any possible target string that could have an overwriting problem. If none exist, we edit in place. Otherwise, we first make a copy. Prior to this commit, the code failed to account for the case where the rhs is shorter than the left, so that any unmatched lhs characters map to the final rhs one. The reason the code didn't consider this is that I didn't think of this possibility when writing it. This fixes #17654 and #17643
khwilliamson
added a commit
that referenced
this issue
Apr 1, 2020
I realized as a result of fixing GH #17654, that the code didn't properly decide if a tr/// can be done in-place on EBCDIC platforms. Our test suite passed, but if we had had valgrind, it would have shown failuress.
khwilliamson
added a commit
that referenced
this issue
Apr 9, 2020
I realized as a result of fixing GH #17654, that the code didn't properly decide if a tr/// can be done in-place on EBCDIC platforms. Our test suite passed, but if we had had valgrind, it would have shown failuress.
khwilliamson
added a commit
that referenced
this issue
Apr 12, 2020
I realized as a result of fixing GH #17654, that the code didn't properly decide if a tr/// can be done in-place on EBCDIC platforms. Our test suite passed, but if we had had valgrind, it would have shown failuress.
khwilliamson
added a commit
that referenced
this issue
May 27, 2020
I realized as a result of fixing GH #17654, that the code didn't properly decide if a tr/// can be done in-place on EBCDIC platforms. Since we didn't have an EBCDIC smoker at the time, I couldn't be sure that the fix actually worked. Now that we do have a smoker, I have successfully tested it. This patch is constructed so that the code generated on non-EBCDIC platforms should not be changed by it.
xsawyerx
pushed a commit
that referenced
this issue
May 27, 2020
I realized as a result of fixing GH #17654, that the code didn't properly decide if a tr/// can be done in-place on EBCDIC platforms. Since we didn't have an EBCDIC smoker at the time, I couldn't be sure that the fix actually worked. Now that we do have a smoker, I have successfully tested it. This patch is constructed so that the code generated on non-EBCDIC platforms should not be changed by it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a bug report for perl from [email protected],
generated with the help of perlbug 1.41 running under perl 5.31.10.
[Please describe your issue here]
While fuzzing perl v5.31.9-70-g0c96aa4b7b built with afl and run
under libdislocator, I found the following program
to cause heap-buffer-overflow. ASAN diagnostics are:
WRITE of size 1 at 0x60200000155a thread T0
#0 0xc74716 in S_do_trans_invmap /home/afl/afl-asan/doop.c:567:5
#1 0xc74716 in Perl_do_trans /home/afl/afl-asan/doop.c:623
#2 0xae0341 in Perl_pp_trans /home/afl/afl-asan/pp.c:692:13
#3 0x8efa3e in Perl_runops_debug /home/afl/afl-asan/dump.c:2571:23
#4 0x61fd94 in S_run_body /home/afl/afl-asan/perl.c
#5 0x61f1f6 in perl_run /home/afl/afl-asan/perl.c:2687:2
#6 0x5352f3 in main /home/afl/afl-asan/perlmain.c:134:9
#7 0x7feb7f05909a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#8 0x43ccb9 in _start (/home/afl/afl-asan/perl+0x43ccb9)
0x60200000155a is located 0 bytes to the right of 10-byte region [0x602000001550,0x60200000155a)
allocated by thread T0 here:
#0 0x501a90 in malloc (/home/afl/afl-asan/perl+0x501a90)
#1 0x8f59e6 in Perl_safesysmalloc /home/afl/afl-asan/util.c:155:21
#2 0xa1b53e in Perl_sv_grow /home/afl/afl-asan/sv.c:1599:17
#3 0xa38681 in Perl_sv_setpvn /home/afl/afl-asan/sv.c:4976:12
#4 0xa86713 in Perl_newSVpvn_flags /home/afl/afl-asan/sv.c:9336:5
#5 0x9f43d0 in Perl_pp_subst /home/afl/afl-asan/pp_hot.c:4387:9
#6 0x8efa3e in Perl_runops_debug /home/afl/afl-asan/dump.c:2571:23
#7 0x61fd94 in S_run_body /home/afl/afl-asan/perl.c
#8 0x61f1f6 in perl_run /home/afl/afl-asan/perl.c:2687:2
#9 0x5352f3 in main /home/afl/afl-asan/perlmain.c:134:9
#10 0x7feb7f05909a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Though this particular buffer overflow is a regression in blead, it has never behaved well, emitting 'panic: swash_fetch got swatch of unexpected bit width, slen=512, needents=64' on perls <= 5.30. Bisect points to the following range:
The first bad commit could be any of:
8c90d3a
Author: Karl Williamson [email protected]
AuthorDate: Wed Oct 2 22:34:37 2019 -0600
Commit: Karl Williamson [email protected]
CommitDate: Wed Nov 6 21:22:24 2019 -0700
intrpvar.h: Add variable for use in tr///
f34acfe
Author: Karl Williamson [email protected]
AuthorDate: Mon Nov 4 21:30:48 2019 -0700
Commit: Karl Williamson [email protected]
CommitDate: Wed Nov 6 21:22:24 2019 -0700
Reimplement tr/// without swashes
We cannot bisect more!
[Please do not change anything below this line]
Flags:
category=core
severity=high
Site configuration information for perl 5.31.10:
Configured by root at Fri Mar 13 17:15:02 MSK 2020.
Summary of my perl5 (revision 5 version 31 subversion 10) configuration:
Commit id: 0c96aa4
Platform:
osname=linux
osvers=4.19.0-8-amd64
archname=x86_64-linux
uname='linux dorothy 4.19.0-8-amd64 #1 smp debian 4.19.98-1 (2020-01-26) x86_64 gnulinux '
config_args='-de -Dusedevel -Doptimize=-O2'
hint=recommended
useposix=true
d_sigaction=define
useithreads=undef
usemultiplicity=undef
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='cc'
ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
optimize='-O2'
cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
ccversion=''
gccversion='8.3.0'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='cc'
ldflags =' -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.28.so
so=so
useshrplib=false
libperl=libperl.a
gnulibc_version='2.28'
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=so
d_dlsymun=undef
ccdlflags='-Wl,-E'
cccdlflags='-fPIC'
lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'
@inc for perl 5.31.10:
lib
/usr/local/lib/perl5/site_perl/5.31.10/x86_64-linux
/usr/local/lib/perl5/site_perl/5.31.10
/usr/local/lib/perl5/5.31.10/x86_64-linux
/usr/local/lib/perl5/5.31.10
Environment for perl 5.31.10:
HOME=/home/afl
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE=en_US.UTF-8
LC_TIME=C
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/home/afl/perlbrew/bin:/home/afl/perlbrew/perls/perl-5.30.0-dbg/bin:/opt/local/bin:/usr/texbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PERLBREW_HOME=/home/afl/.perlbrew
PERLBREW_MANPATH=/home/afl/perlbrew/perls/perl-5.30.0-dbg/man
PERLBREW_PATH=/home/afl/perlbrew/bin:/home/afl/perlbrew/perls/perl-5.30.0-dbg/bin
PERLBREW_PERL=perl-5.30.0-dbg
PERLBREW_ROOT=/home/afl/perlbrew
PERLBREW_SHELLRC_VERSION=0.88
PERLBREW_VERSION=0.88
PERL_BADLANG (unset)
The text was updated successfully, but these errors were encountered: