If you compile and build your own image, would that be able to trigger the backdoor?
You can of course change an existing image to something that triggers the backdoor, but with that level of access you won't really need a backdoor, do you?
1. A new "test" is added to the xz-utils repository, and when xz is being built by a distribution such as Debian, the backdoor from the "test" is included into the xz binary.
2. The backdoored xz is distributed widely, including to a target vendor who wishes to from a Debian development environment compile a kernel for an embedded device that is usually used in a specific industry and/or set of countries.
3. When backdoored xz is then asked to compress a file, it checks whether the file is a kernel image and checks whether the kernel image is for the intended target (e.g. includes specific set of drivers).
4. If the backdoored xz has found its target kernel image, search for and modify random number generation code to effectively make it deterministic. Or add a new module which listens on PF_CAN interfaces for a particular trigger and then sends malicious CAN messages over that interface. Or modify dm_crypt to overwrite the first 80% of any key with a hardcoded value. Plenty of nasty ideas are possible.
Note that none of these steps require the attacker to have any code in the kernel. The kernel patchset is completely orthogonal to the possibility of this attack, and seems to be benign.
It's Thompson's "Trusting Trust"[1], right? To the extent XZ is part of the standard build chain you could have a source-invisible replicating vulnerability that infects everything. And if it gets into the image used for, say, a popular mobile device or IoT gadget...
If you compile and build your own image, would that be able to trigger the backdoor?
You can of course change an existing image to something that triggers the backdoor, but with that level of access you won't really need a backdoor, do you?