It is a fixed bug. Your target needs to be an outdated Linux distro.

In a current one or patched one, is more likely to have a non-vulnerable LUKS2 volume that you can not downgrade to a vulnerable one, or a kernel and userspace tools non-vulnerable to the metadata manipulation even for a LUKS1 volume.

I concede the plausible scenario of replacing the kernel to a vulnerable one, if you ha access to the drive (by external OS boot or get the hardware) and replacing the kernel on the usually unencrypted boot partition along modifying the LUKS2 metadata of the encrypted volume. Not a quick local or remote feat to do. Not doable on an encrypted boot volume or signed boot files (secure boot thingy). Sincerely, if you have that kind of access, it is easier to modify the initramfs file to grab the LUKS key.

According to [0] attacks from a cold device require two steps of physical access. That would bypass signed contents of a boot partition, since you're messing with unprotected LUKS header contents.

If the contents of the boot partition are unsigned there are probably easier attacks available. You could, for instance, deploy a kernel with crafted reencryption logic baked in over the default boot kernel. That wouldn't require this vulnerability, because the victim will be typing the passphrase into the attacker's (unprotected) kernel from /boot.

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=2032401