When the maximum count of SCRIPTS instructions is reached, the code
stops execution and returns, but fails to decrement the reentrancy
counter. This effectively renders the SCSI controller unusable
because on next entry the reentrancy counter is still above the limit.

This bug was seen on HP-UX 10.20 which seems to trigger SCRIPTS
loops.

Fixes: b987718bbb ("hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI controller (CVE-2023-0330)")
Signed-off-by: Sven Schnelle <svens@stackframe.org>
---
 hw/scsi/lsi53c895a.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
index 34e3b89287..d607a5f9fb 100644
--- a/hw/scsi/lsi53c895a.c
+++ b/hw/scsi/lsi53c895a.c
@@ -1159,6 +1159,7 @@ again:
         lsi_script_scsi_interrupt(s, LSI_SIST0_UDC, 0);
         lsi_disconnect(s);
         trace_lsi_execute_script_stop();
+        reentrancy_level--;
         return;
     }
     insn = read_dword(s, s->dsp);
-- 
2.43.0

On 1/28/24 21:22, Sven Schnelle wrote:
> When the maximum count of SCRIPTS instructions is reached, the code
> stops execution and returns, but fails to decrement the reentrancy
> counter. This effectively renders the SCSI controller unusable
> because on next entry the reentrancy counter is still above the limit.
>
> This bug was seen on HP-UX 10.20 which seems to trigger SCRIPTS
> loops.
>
> Fixes: b987718bbb ("hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI controller (CVE-2023-0330)")
> Signed-off-by: Sven Schnelle <svens@stackframe.org>

Tested-by: Helge Deller <deller@gmx.de>

Thanks!
Helge

> ---
>   hw/scsi/lsi53c895a.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
> index 34e3b89287..d607a5f9fb 100644
> --- a/hw/scsi/lsi53c895a.c
> +++ b/hw/scsi/lsi53c895a.c
> @@ -1159,6 +1159,7 @@ again:
>           lsi_script_scsi_interrupt(s, LSI_SIST0_UDC, 0);
>           lsi_disconnect(s);
>           trace_lsi_execute_script_stop();
> +        reentrancy_level--;
>           return;
>       }
>       insn = read_dword(s, s->dsp);

28.01.2024 23:22, Sven Schnelle :
> When the maximum count of SCRIPTS instructions is reached, the code
> stops execution and returns, but fails to decrement the reentrancy
> counter. This effectively renders the SCSI controller unusable
> because on next entry the reentrancy counter is still above the limit.
> 
> This bug was seen on HP-UX 10.20 which seems to trigger SCRIPTS
> loops.

Cc: qemu-stable@

/mjt

On 28/01/2024 21.22, Sven Schnelle wrote:
> When the maximum count of SCRIPTS instructions is reached, the code
> stops execution and returns, but fails to decrement the reentrancy
> counter. This effectively renders the SCSI controller unusable
> because on next entry the reentrancy counter is still above the limit.
> 
> This bug was seen on HP-UX 10.20 which seems to trigger SCRIPTS
> loops.

Out of curiosity: What happened there before we introduced the 
reentrancy_level fix? Did it end up in an endless loop, or was it finishing 
at one point? In the latter case, we might need to adjust the 
"reentrancy_level > 8" to allow deeper nesting.

> Fixes: b987718bbb ("hw/scsi/lsi53c895a: Fix reentrancy issues in the LSI controller (CVE-2023-0330)")
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
> ---
>   hw/scsi/lsi53c895a.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
> index 34e3b89287..d607a5f9fb 100644
> --- a/hw/scsi/lsi53c895a.c
> +++ b/hw/scsi/lsi53c895a.c
> @@ -1159,6 +1159,7 @@ again:
>           lsi_script_scsi_interrupt(s, LSI_SIST0_UDC, 0);
>           lsi_disconnect(s);
>           trace_lsi_execute_script_stop();
> +        reentrancy_level--;
>           return;
>       }
>       insn = read_dword(s, s->dsp);

Reviewed-by: Thomas Huth <thuth@redhat.com>

Thomas Huth <thuth@redhat.com> writes:

> On 28/01/2024 21.22, Sven Schnelle wrote:
>> When the maximum count of SCRIPTS instructions is reached, the code
>> stops execution and returns, but fails to decrement the reentrancy
>> counter. This effectively renders the SCSI controller unusable
>> because on next entry the reentrancy counter is still above the limit.
>> This bug was seen on HP-UX 10.20 which seems to trigger SCRIPTS
>> loops.
>
> Out of curiosity: What happened there before we introduced the
> reentrancy_level fix? Did it end up in an endless loop, or was it
> finishing at one point? In the latter case, we might need to adjust
> the "reentrancy_level > 8" to allow deeper nesting.

Without the reentrancy counter it was triggering the insn_processed
limit. The HP-UX scsi driver seems to spin on some memory value during
some SCSI writes (CDB with command 0x2a). So it is spinning in an
endless loop until the insn_processed counter will trigger the exit.
In HP-UX you will see a SCSI command timeout error in the kernel log
- at least i'm assuming that's related, but can't say for sure as
there's no kernel source available.