A secure boot bypass by finding an issue before the boot image has been verified.

This is a common attack surface with secure boot systems, integrity needs to be verified before executing, but the code that initializes the system so that the integrity check can even run must be executed first. Giving a small window of opportunity to find an issue that can compromise control flow and take over the system. In this case the first step was from the "Register Initialization List (RIL) which contains pairs of addresses and data that would be used for initialization of the system. These pairs were also restricted by the presence of a secure boot flag in the header. Since this flag isn’t checked until after things are used however, an attacker could modify it to use the less secure boot process and gain a bit more attack surface through the extra RIL entries that would be used during a non-secure boot.

I had some trouble following the original post with regards to how these values were abused. Likely due to my own unfamiliarity with the area of research and that this is the 4th part in a series that looks to provide my background, but I found the CVE description useful for the general idea:

… they will be able to modify the full range of register initialization values. Normally, these registers will be restricted when booting securely. Of importance to this attack are two registers that control the SD card’s transfer type and transfer size. These registers could be modified a way that causes a buffer overflow in the ROM.

Which indicates the transfer type and size were used to obtain an overflow, the post does talk about using this overflow to compromise the boot_func pointer. The post dives more into the specific exploit details.