From: sashiko-bot@kernel.org
To: "Bart Van Assche" <bvanassche@acm.org>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi: pm8001: Fix SATA FIS offset in struct hw_event_resp
Date: Mon, 31 Aug 2026 20:07:05 +0000 [thread overview]
Message-ID: <20260831200706.281131F000E9@smtp.kernel.org> (raw)
In-Reply-To: <31963d53810f42970447e78ef46030ab13d2e91f.1788198434.git.bvanassche@acm.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing bounds checks for unvalidated `port_id` and `phy_id` extracted from hardware payloads in hardware event handlers, leading to potential out-of-bounds array accesses.
--
commit 54581172c25d0fbd24fe1a048aa6e9fe28d5e2e9
Author: Bart Van Assche <bvanassche@acm.org>
scsi: pm8001: Fix SATA FIS offset in struct hw_event_resp
This commit fixes a Clang compiler warning about negative pointer
arithmetic by properly defining the SATA FIS offset in the struct
hw_event_resp. It extracts the 28-byte identify frame into a
separate struct and aligns the sata_fis member to its actual
hardware byte offset.
[ ... ]
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c b/drivers/scsi/pm8001/pm80xx_hwi.c
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -3296,7 +3296,7 @@ hw_event_sata_phy_up(struct pm8001_hba_info *pm8001_ha, void *piomb)
[Severity: High]
This is a pre-existing issue, but does this function lack bounds checking
on the port_id and phy_id extracted from the hardware payload?
Looking earlier in hw_event_sata_phy_up():
u8 port_id = (u8)(lr_status_evt_portid & 0x000000FF);
u8 phy_id = (u8)((phyid_npip_portstate & 0xFF0000) >> 16);
...
struct pm8001_port *port = &pm8001_ha->port[port_id];
struct pm8001_phy *phy = &pm8001_ha->phy[phy_id];
Since port_id and phy_id can be up to 255 based on the bitwise masking,
and the port and phy arrays are statically sized to PM8001_MAX_PHYS (16),
could a malfunctioning or untrusted hardware payload cause out-of-bounds
array accesses here?
A similar pattern also appears to exist in pm80xx_mpi_hw_event() when
handling untrusted event payloads.
> phy->sas_phy.oob_mode = SATA_OOB_MODE;
> sas_notify_phy_event(&phy->sas_phy, PHYE_OOB_DONE, GFP_ATOMIC);
> spin_lock_irqsave(&phy->sas_phy.frame_rcvd_lock, flags);
> - memcpy(phy->frame_rcvd, ((u8 *)&pPayload->sata_fis - 4),
> + memcpy(phy->frame_rcvd, &pPayload->sata_fis,
> sizeof(struct dev_to_host_fis));
> phy->frame_rcvd_size = sizeof(struct dev_to_host_fis);
> phy->identify.target_port_protocols = SAS_PROTOCOL_SATA;
--
Sashiko AI review · https://sashiko.dev/#/patchset/31963d53810f42970447e78ef46030ab13d2e91f.1788198434.git.bvanassche@acm.org?part=1
prev parent reply other threads:[~2026-08-31 20:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 17:48 [PATCH] scsi: pm8001: Fix SATA FIS offset in struct hw_event_resp Bart Van Assche
2026-08-31 20:07 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260831200706.281131F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bvanassche@acm.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox