[PATCH] scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE

[PATCH] scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE

[kensanya]

From: TanZheng <tanzheng@kylinos.cn>

In the iblock_execute_pr_out function, PRO_PREEMPT, PRO_PREEMPT_AND_ABORT
and PRO_RELEASE all perform callback capability checks through
ops->pr_clear. The error check allows unimplemented hooks to pass through
the gate, resulting  dereferencing a NULL function pointer.

Check whether the hooks that need to be called are supported.

Fixes: 394f81184882 ("scsi: target: Add block PR support to iblock")
Signed-off-by: TanZheng <tanzheng@kylinos.cn>
---
 drivers/target/target_core_iblock.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index 1087d1d17c36..ea65d39fef88 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -906,7 +906,7 @@ static sense_reason_t iblock_execute_pr_out(struct se_cmd *cmd, u8 sa, u64 key,
 		break;
 	case PRO_PREEMPT:
 	case PRO_PREEMPT_AND_ABORT:
-		if (!ops->pr_clear) {
+		if (!ops->pr_preempt) {
 			pr_err("block_device does not support pr_preempt.\n");
 			return TCM_UNSUPPORTED_SCSI_OPCODE;
 		}
@@ -916,8 +916,8 @@ static sense_reason_t iblock_execute_pr_out(struct se_cmd *cmd, u8 sa, u64 key,
 				      sa == PRO_PREEMPT_AND_ABORT);
 		break;
 	case PRO_RELEASE:
-		if (!ops->pr_clear) {
-			pr_err("block_device does not support pr_pclear.\n");
+		if (!ops->pr_release) {
+			pr_err("block_device does not support pr_release.\n");
 			return TCM_UNSUPPORTED_SCSI_OPCODE;
 		}
 
-- 
2.25.1

Re: [PATCH] scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Un-ratelimited error logging can be abused by an initiator to flood the kernel log.
--

--- Patch [1]: [PATCH] scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE ---
commit 562d965ef4dd6b2eb1b1b38dac4b060b92e2df13
Author: TanZheng <tanzheng@kylinos.cn>

scsi: target: iblock: Fix wrong PR ops NULL check for PREEMPT/RELEASE
    
This commit corrects a bug in the iblock_execute_pr_out function where the
pr_clear callback was being checked instead of the corresponding pr_preempt
and pr_release callbacks. This fixes a potential NULL pointer dereference
if those specific PR ops are unimplemented.

> --- a/drivers/target/target_core_iblock.c
> +++ b/drivers/target/target_core_iblock.c
> @@ -906,7 +906,7 @@ static sense_reason_t iblock_execute_pr_out(struct se_cmd *cmd, u8 sa, u64 key,
>  		break;
>  	case PRO_PREEMPT:
>  	case PRO_PREEMPT_AND_ABORT:
> -		if (!ops->pr_clear) {
> +		if (!ops->pr_preempt) {
>  			pr_err("block_device does not support pr_preempt.\n");

[Severity: High]
This is a pre-existing issue, but could this un-ratelimited error logging be
abused by a remote initiator to flood the kernel log?

If a malicious or misbehaving SCSI initiator repeatedly sends PR OUT commands
with unsupported operations, it will hit this pr_err() at a high frequency.
This could flood the dmesg buffer, hide other critical messages, and
potentially cause resource exhaustion.

This same pattern exists throughout iblock_execute_pr_out, including the
default switch case for unknown Service Actions:

    default:
        pr_err("Unknown PERSISTENT_RESERVE_OUT SA: 0x%02x\n", sa);
        return TCM_UNSUPPORTED_SCSI_OPCODE;

Would it be safer to use pr_err_ratelimited() for these initiator-triggerable
errors?

>  			return TCM_UNSUPPORTED_SCSI_OPCODE;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724075850.280699-1-kensanya@163.com?part=1