Incorrect stalling behaviour for configurations with writeback stage but without branch target ALU results in an incorrect branch target

Observed Behavior

If the top level data_gnt_i signal is either constantly high, or it is high at certain clock cycles (without an outstanding request), and a load is followed by a branch, the fetch address is set to the comparison result of the branch.

• If this value is resembling an aligned address, Ibex continues executing at this address. This allows an attacker to obtain arbitrary code execution controlled by the data values used in the branch comparison.
  

• If the branch comparison result resembles a misaligned address, the incoming instructions are interpreted misaligned, which turns a NOP into an illegal instruction (0x00010413 in the screenshot), causing an exception.
  

Expected Behavior

Ibex should not divert the control flow in data-dependent ways in case of unsolicited data grants.

Steps to reproduce the issue

I created a small sample setup that shows the bug in the latest code version (and also with the fix for #2144).
https://github.com/KatCe/ibex/blob/bug_cf_hijack_load_branch/dv/bug_cf_hijack_load_branch/tb_top.sv

My Environment

EDA tool and version:
Modelsim

Operating system:
Ubuntu 20.04.6 LTS

Version of the Ibex source code:
eea2bf0c1c62bbd676edf69cc60a56041d53b669
SecureIbex (configuration see testbench)

Start with the reproduction in dv/bug_cf_hijack_load_branch/tb_top.sv and trace the top-level data_gnt_i behavior for a load followed by a branch. Inspect the writeback-stage configuration and branch-target handling; done means unsolicited data grants no longer divert control flow or produce a misaligned instruction exception.