https://bugs.kde.org/show_bug.cgi?id=471036
Bug ID: 471036
Summary: disInstr_AMD64: disInstr miscalculated next %rip on
RORX imm8, m32/64, r32/64
Classification: Developer tools
Product: valgrind
Version: 3.22 GIT
Platform: Other
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: redo...@redoste.xyz
Target Milestone: ---
Created attachment 159661
--> https://bugs.kde.org/attachment.cgi?id=159661&action=edit
Example program containing the RORX instruction
SUMMARY
A program with the "RORX imm8, m32/64, r32/64" instruction will crash Valgrind
with an off by one between the assumed next %rip and the actual next %rip.
STEPS TO REPRODUCE
1. Assemble the example program which uses the RORX instruction
2. Run with Valgrind
OBSERVED RESULT
$ ./vg-in-place -v --tool=none ./../mwe
==2174== Nulgrind, the minimal Valgrind tool
==2174== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote.
==2174== Using Valgrind-3.22.0.GIT-3df8a00a4e-20230609 and LibVEX; rerun with
-h for copyright info
==2174== Command: ./../mwe
==2174==
--2174-- Valgrind options:
--2174-- -v
--2174-- --tool=none
--2174-- Contents of /proc/version:
--2174-- Linux version 6.3.5_1 (voidlinux@voidlinux) (gcc (GCC) 12.2.0, GNU
ld (GNU Binutils) 2.39) #1 SMP PREEMPT_DYNAMIC Wed May 31 02:29:35 UTC 2023
--2174--
--2174-- Arch and hwcaps: AMD64, LittleEndian,
amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed
--2174-- Page sizes: currently 4096, max supported 4096
--2174-- Valgrind library directory: /tmp/tmp/valgrind/./.in_place
--2174-- Reading syms from /tmp/tmp/valgrind/none/none-amd64-linux
--2174-- object doesn't have a dynamic symbol table
--2174-- Scheduler: using generic scheduler lock implementation.
==2174== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-2174-by-redoste-on-???
==2174== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-2174-by-redoste-on-???
==2174== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-2174-by-redoste-on-???
==2174==
==2174== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2174== don't want to do, unless you know exactly what you're doing,
==2174== or are doing some strange experiment):
==2174== /tmp/tmp/valgrind/./.in_place/../../bin/vgdb --pid=2174
...command...
==2174==
==2174== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2174== /path/to/gdb ./../mwe
==2174== and then give GDB the following command
==2174== target remote | /tmp/tmp/valgrind/./.in_place/../../bin/vgdb
--pid=2174
==2174== --pid is optional if only one valgrind process is running
==2174==
assumed next %rip = 0x401009
actual next %rip = 0x40100A
vex: the `impossible' happened:
disInstr_AMD64: disInstr miscalculated next %rip
vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
host stacktrace:
==2174== at 0x5802873A: show_sched_status_wrk (m_libcassert.c:406)
==2174== by 0x58028857: report_and_quit (m_libcassert.c:477)
==2174== by 0x58028AAB: vgPlain_core_panic_at (m_libcassert.c:553)
==2174== by 0x58028ACA: vgPlain_core_panic (m_libcassert.c:563)
==2174== by 0x5803EC24: failure_exit (m_translate.c:761)
==2174== by 0x580F319A: vpanic (main_util.c:253)
==2174== by 0x581801CE: disInstr_AMD64 (guest_amd64_toIR.c:32698)
==2174== by 0x5810B759: disassemble_basic_block_till_stop.constprop.0
(guest_generic_bb_to_IR.c:956)
==2174== by 0x5810C2F4: bb_to_IR (guest_generic_bb_to_IR.c:1365)
==2174== by 0x580F0252: LibVEX_FrontEnd (main_main.c:583)
==2174== by 0x580F0BAC: LibVEX_Translate (main_main.c:1235)
==2174== by 0x580414AB: vgPlain_translate (m_translate.c:1831)
==2174== by 0x580131B4: vgPlain_scheduler (scheduler.c:1136)
==2174== by 0x5807EF19: run_a_thread_NORETURN (syswrap-linux.c:102)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable (lwpid 2174)
==2174== at 0x401000: ??? (in /tmp/tmp/mwe)
client stack range: [0x1FFEFFF000 0x1FFF000FFF] client SP: 0x1FFF0000C0
valgrind stack range: [0x100268E000 0x100278DFFF] top usage: 5960 of 1048576
EXPECTED RESULT
$ ./vg-in-place -v --tool=none ./../mwe
==2890== Nulgrind, the minimal Valgrind tool
==2890== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote.
==2890== Using Valgrind-3.22.0.GIT-3df8a00a4e-20230609X and LibVEX; rerun with
-h for copyright info
==2890== Command: ./../mwe
==2890==
--2890-- Valgrind options:
--2890-- -v
--2890-- --tool=none
--2890-- Contents of /proc/version:
--2890-- Linux version 6.3.5_1 (voidlinux@voidlinux) (gcc (GCC) 12.2.0, GNU
ld (GNU Binutils) 2.39) #1 SMP PREEMPT_DYNAMIC Wed May 31 02:29:35 UTC 2023
--2890--
--2890-- Arch and hwcaps: AMD64, LittleEndian,
amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed
--2890-- Page sizes: currently 4096, max supported 4096
--2890-- Valgrind library directory: /tmp/tmp/valgrind/./.in_place
--2890-- Reading syms from /tmp/tmp/valgrind/none/none-amd64-linux
--2890-- object doesn't have a dynamic symbol table
--2890-- Scheduler: using generic scheduler lock implementation.
==2890== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-2890-by-redoste-on-???
==2890== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-2890-by-redoste-on-???
==2890== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-2890-by-redoste-on-???
==2890==
==2890== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2890== don't want to do, unless you know exactly what you're doing,
==2890== or are doing some strange experiment):
==2890== /tmp/tmp/valgrind/./.in_place/../../bin/vgdb --pid=2890
...command...
==2890==
==2890== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2890== /path/to/gdb ./../mwe
==2890== and then give GDB the following command
==2890== target remote | /tmp/tmp/valgrind/./.in_place/../../bin/vgdb
--pid=2890
==2890== --pid is optional if only one valgrind process is running
==2890==
==2890==
SOFTWARE/OS VERSIONS
$ uname -a
Linux hostname 6.3.5_1 #1 SMP PREEMPT_DYNAMIC Wed May 31 02:29:35 UTC 2023
x86_64 GNU/Linux
ADDITIONAL INFORMATION
I'm not completely sure about the fix but a patch for
VEX/priv/guest_amd64_toIR.c correcting the off by one on RORX disassembly is
attached.
--
You are receiving this mail because:
You are watching all bug changes.
