Re: Always investigate valgrind memcheck errors [[email protected]: Re: xz backdoor]

Paul Floyd via Valgrind-users <[email protected]> Sun, 31 Mar 2024 16:45:54 +0000
Newsgroups gmane.comp.debugging.valgrind
Message-ID <[email protected]>

On 30-03-24 11:43, Mark Wielaard wrote:
> For those of you tracking the xz backdoor:
> https://lwn.net/Articles/967180/
> 
> valgrind plays a little role in the discovery.
> 
> "Then recalled that I had seen an odd valgrind complaint in my
> automated testing of postgres, a few weeks earlier, after some package
> updates were installed."  https://lwn.net/Articles/967194/
> 
> See also the attached email, which talks about this bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=2267598
> 
> So please always take valgrind memcheck errors seriously and
> investigate them!
> 
> P.S. Sourceware isn't impacted by this xz backdoor:
> https://fosstodon.org/@sourceware/112180412918966168
> But we did reset the buildbot containers of the affected distros.

Hi Mark

I think RedHat did a good job in the circumstances. It's not easy to 
keep out bad faith attacks like this.

The call stack does look peculiar, particularly the addresses 0x6 and 
0x77AD31E59B84CFFF. It would be interesting to see if there is anything 
mapped to those addresses. 0x1FFEFFF4AF is somewhere around the client 
stack.

I suppose that a debug build would only give more information on the top 
two levels.

==746855== Invalid write of size 8
==746855==    at 0x52E8645: ??? (in /usr/lib64/liblzma.so.5.6.0)
==746855==    by 0x52CA83B: _get_cpuid (in /usr/lib64/liblzma.so.5.6.0)
==746855==    by 0x6: ???
==746855==    by 0x1FFEFFF4AF: ???
==746855==    by 0x77AD31E59B84CFFF: ???
==746855==    by 0x1FFEFFF4AF: ???
==746855==    by 0x400F253: elf_machine_rela (dl-machine.h:314)
==746855==    by 0x400F253: elf_dynamic_do_Rela (do-rel.h:147)
==746855==    by 0x400F253: _dl_relocate_object (dl-reloc.c:301)

A+
Paul