All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Hyeoncheol Jeong" <hyenc.jeong@samsung.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 2/2] scsi: ufs: Serve the device init reads from one aggregated read
Date: Mon, 14 Sep 2026 09:03:13 +0000	[thread overview]
Message-ID: <20260914090313.DD0C81F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260914084258epcms2p22f5bea4edaa975dcdcb7d6c838ffd440@epcms2p2>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Potential unaligned memory access when parsing malicious or buggy UFS 5.0 aggregated read packets.
--

commit 6958e42c99c17e67c3aba30be65b988c84328c42
Author: Hyeoncheol Jeong <hyenc.jeong@samsung.com>

scsi: ufs: Serve the device init reads from one aggregated read

The commit caches a UFS 5.0 AGGREGATED READ payload into a buffer during
initialization and serves individual attribute, flag, and string descriptor
requests from the cached packet.

> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index e0254ddb31729..05a2f4532be5d 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c

[ ... ]

> @@ -3816,6 +3816,313 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
>  	return err;
>  }
>  
[ ... ]
> +/**
> + * ufshcd_agg_group - find a group in the cached aggregated data packet
> + * @hba: per-adapter instance
> + * @type: group type to find
> + * @group_len: set to the group payload length on a hit
> + *
> + * Return: the group payload, or NULL if @type is not present.
> + */
> +static const u8 *ufshcd_agg_group(const struct ufs_hba *hba, u8 type,
> +				  u16 *group_len)
> +{
> +	const u8 *packet = hba->agg_packet;
> +	u16 hdr_off = 0;
> +
> +	while (packet && hdr_off + QUERY_AGG_GROUP_HDR_SIZE <= hba->agg_packet_len) {
> +		const struct utp_agg_group_header *hdr =
> +			(const void *)(packet + hdr_off);
> +		u16 next_off = be16_to_cpu(hdr->next_group_offset);

[Severity: High]
Can this cause an unaligned memory access crash on strict-alignment
architectures?

Since struct utp_agg_group_header lacks the __packed attribute, the compiler
expects instances of this struct to be 2-byte aligned.

If a UFS device returns an odd value for next_group_offset in the payload,
hdr_off will be odd on the next iteration. Casting packet + hdr_off to
struct utp_agg_group_header * and dereferencing hdr->next_group_offset
would cause the compiler to emit an aligned 16-bit load instruction.

If the pointer is unaligned, this can lead to a hardware alignment exception
when dereferenced. Should this code validate the alignment, use
get_unaligned_be16(), or define struct utp_agg_group_header as __packed?

> +		u16 payload_off = hdr_off + QUERY_AGG_GROUP_HDR_SIZE;
> +
> +		if (next_off && (next_off < payload_off ||
> +				 next_off + QUERY_AGG_GROUP_HDR_SIZE > hba->agg_packet_len))
> +			return NULL;
> +
> +		if (hdr->group_type == type) {
> +			*group_len = (next_off ? next_off : hba->agg_packet_len) -
> +				     payload_off;
> +			return packet + payload_off;
> +		}
> +
> +		if (!next_off)
> +			break;
> +
> +		hdr_off = next_off;
> +	}
> +
> +	return NULL;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914083838epcms2p1336cbd08ce6ed192eeed9adbad365a93@epcms2p1?part=2

      reply	other threads:[~2026-09-14  9:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260914083838epcms2p1336cbd08ce6ed192eeed9adbad365a93@epcms2p1>
2026-09-14  8:38 ` [PATCH 0/2] scsi: ufs: batch device-init reads with UFS 5.0 aggregated read Hyeoncheol Jeong
2026-09-14  8:41   ` [PATCH 1/2] scsi: ufs: Add the aggregated read query opcode and its reply format Hyeoncheol Jeong
2026-09-14  8:42   ` [PATCH 2/2] scsi: ufs: Serve the device init reads from one aggregated read Hyeoncheol Jeong
2026-09-14  9:03     ` 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=20260914090313.DD0C81F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=hyenc.jeong@samsung.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.