Bug 478624

Summary:	Valgrind incompatibility with binutils-2.42 on x86 with new nop patterns (unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26)
Product:	[Developer tools] valgrind	Reporter:	Sam James <sam>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	RESOLVED FIXED
Severity:	normal	CC:	aurelien, debfx-kde, mark, pjfloyd, schwab, sj
Priority:	NOR
Version First Reported In:	3.22 GIT
Target Milestone:	---
Platform:	Other
OS:	Other
See Also:	http://bugs.debian.org/1057693
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Sam James 2023-12-17 01:10:56 UTC

[Forgive me, as I've not yet hit this myself, but reporting it based on the Debian bug after discussing it with mjw.]

The upcoming binutils-2.42 release [0] seems to be incompatible with Valgrind on x86 after a commit landed [1] to emit additional nop patterns which Valgrind doesn't yet recognise.

This was originally reported in Debian [2] (CC'd some of the participants whose emails I could find on here).

In the linked Debian bug, Simon gives a simple reproducer w/ output:
```

117s vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26
117s ==5711== valgrind: Unrecognised instruction at address 0x4d285c8.
117s ==5711==    at 0x4D285C8: ??? (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x4D27893: ??? (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x4D27B0E: ??? (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x4D27069: gss_import_name (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x486BA0F: ??? (in /usr/lib/i386-linux-gnu/libgsasl.so.18.0.0)
117s ==5711==    by 0x485757C: gsasl_step (in /usr/lib/i386-linux-gnu/libgsasl.so.18.0.0)
117s ==5711==    by 0x4857623: gsasl_step64 (in /usr/lib/i386-linux-gnu/libgsasl.so.18.0.0)
117s ==5711==    by 0x10B387: ??? (in /usr/bin/gsasl)
117s ==5711==    by 0x4ADE7C4: (below main) (libc_start_call_main.h:58)
117s ==5711== Your program just tried to execute an instruction that Valgrind
117s ==5711== did not recognise.  There are two possible reasons for this.
117s ==5711== 1. Your program has a bug and erroneously jumped to a non-code
117s ==5711==    location.  If you are running Memcheck and you just saw a
117s ==5711==    warning about a bad jump, it's probably your program's fault.
117s ==5711== 2. The instruction is legitimate but Valgrind doesn't handle it,
117s ==5711==    i.e. it's Valgrind's fault.  If you think this is the case or
117s ==5711==    you are not sure, please let us know and we'll try to fix it.
117s ==5711== Either way, Valgrind will now raise a SIGILL signal which will
117s ==5711== probably kill your program.
117s ==5711== 
117s ==5711== Process terminating with default action of signal 4 (SIGILL)
117s ==5711==  Illegal opcode at address 0x4D285C8
117s ==5711==    at 0x4D285C8: ??? (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x4D27893: ??? (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x4D27B0E: ??? (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x4D27069: gss_import_name (in /usr/lib/i386-linux-gnu/libgssglue.so.1.0.0)
117s ==5711==    by 0x486BA0F: ??? (in /usr/lib/i386-linux-gnu/libgsasl.so.18.0.0)
117s ==5711==    by 0x485757C: gsasl_step (in /usr/lib/i386-linux-gnu/libgsasl.so.18.0.0)
117s ==5711==    by 0x4857623: gsasl_step64 (in /usr/lib/i386-linux-gnu/libgsasl.so.18.0.0)
117s ==5711==    by 0x10B387: ??? (in /usr/bin/gsasl)
117s ==5711==    by 0x4ADE7C4: (below main) (libc_start_call_main.h:58)
```

with steps to reproduce:
```
podman run --arch 386  -it --rm debian:unstable-slim
apt update
apt install valgrind gsasl
apt dist-upgrade
valgrind --error-exitcode=1 /usr/bin/gsasl -m GSSAPI -d --no-starttls --imap no-such-domain.example 143
```

[0] https://inbox.sourceware.org/binutils/0f118fd8-5630-4742-a353-3309e6285ea7@redhat.com/T/#u
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ad9f3230565ca40bfa1d9a3106aaaa272cb125f2
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057693

Comment 1 Sam James 2023-12-17 01:11:15 UTC

<mjw> For a testcase we probably should just have a simple assembly/byte sequence of all the "nops" used in https://sourceware.org/cgit/binutils-gdb/tree/gas/config/tc-i386.c#n1256

Comment 2 Paul Floyd 2023-12-17 14:34:05 UTC

Should be fixed with this. Can someone check with the latest binutils?

commit d35005cef8ad8207542738812705ceabf137d7e0 (HEAD -> master, origin/master, origin/HEAD, gnu_binutils_nop)
Author: Paul Floyd <pjfloyd@wanadoo.fr>
Date:   Sun Dec 17 14:18:51 2023 +0100

    Bug 478624 - Valgrind incompatibility with binutils-2.42 on x86 with new nop patterns (unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26)
    
    It was a bit of a struggle to get the testcase to build
    with both clang and gcc (oddly enough gcc was more difficult) so
    I just resorted to using .byte arrays.

Comment 3 Mark Wielaard 2024-01-22 12:59:10 UTC

Gentoo, Debian and Fedora already pulled in this patch.
Now also added to VALGRIND_3_22_BRANCH:

commit 41ff9aa49f6c54c66d0e6b37f265fd9cb0176057
Author: Paul Floyd <pjfloyd@wanadoo.fr>
Date:   Sun Dec 17 14:18:51 2023 +0100

    Bug 478624 - Valgrind incompatibility with binutils-2.42 on x86 with new nop patterns (unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26)
    
    It was a bit of a struggle to get the testcase to build
    with both clang and gcc (oddly enough gcc was more difficult) so
    I just resorted to using .byte arrays.
    
    (cherry picked from commit d35005cef8ad8207542738812705ceabf137d7e0)

Comment 4 Tom Hughes 2024-02-01 14:07:24 UTC

*** Bug 480680 has been marked as a duplicate of this bug. ***