linux-kernel - Re: [PATCH v5 2/2] usb: typec: ucsi_glink: Increase buffer size to support UCSI v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7390eaf3-0215-49d6-8605-bf573d693ad9@oss.qualcomm.com>
Date: Mon, 6 Oct 2025 12:49:29 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Anjelique Melendez <anjelique.melendez@....qualcomm.com>,
        heikki.krogerus@...ux.intel.com, gregkh@...uxfoundation.org
Cc: lumag@...nel.org, neil.armstrong@...aro.org, johan+linaro@...nel.org,
        quic_bjorande@...cinc.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v5 2/2] usb: typec: ucsi_glink: Increase buffer size to
 support UCSI v2

On 10/3/25 2:20 AM, Anjelique Melendez wrote:
> UCSI v2 specification has increased the MSG_IN and MSG_OUT size from
> 16 bytes to 256 bytes each for the message exchange between OPM and PPM
> This makes the total buffer size increase from 48 bytes to 528 bytes.
> Update the buffer size to support this increase.
> 
> Signed-off-by: Anjelique Melendez <anjelique.melendez@....qualcomm.com>
> ---

[...]

>  static void pmic_glink_ucsi_read_ack(struct pmic_glink_ucsi *ucsi, const void *data, int len)
>  {
> -	const struct ucsi_read_buf_resp_msg *resp = data;
> +	u32 ret_code, resp_len, buf_len = 0;
> +	u8 *buf;
> +
> +	if (ucsi->ucsi->version) {
> +		if (ucsi->ucsi->version >= UCSI_VERSION_2_0) {
> +			buf = ((struct ucsi_read_buf_resp_msg *)data)->buf.v2_buf;
> +			buf_len = UCSI_BUF_V2_SIZE;
> +		} else {
> +			buf = ((struct ucsi_read_buf_resp_msg *)data)->buf.v1_buf;
> +			buf_len = UCSI_BUF_V1_SIZE;
> +		}
> +	} else if (!ucsi->ucsi_registered) {
> +		/*
> +		 * If UCSI version is not known yet because device is not registered, choose buffer
> +		 * size which best fits incoming data
> +		 */
> +		if (len > sizeof(struct pmic_glink_hdr) + UCSI_BUF_V2_SIZE) {
> +			buf = ((struct ucsi_read_buf_resp_msg *)data)->buf.v2_buf;
> +			buf_len = UCSI_BUF_V2_SIZE;
> +		} else {
> +			buf = ((struct ucsi_read_buf_resp_msg *)data)->buf.v1_buf;
> +			buf_len = UCSI_BUF_V1_SIZE;
> +		}
> +	}

else warn & return.. otherwise in an unlikely scenario the rproc sends us
some appropriately-sized garbage, the below size check may still not be enough

> +	resp_len = sizeof(struct pmic_glink_hdr) + buf_len + sizeof(u32);
>  
> -	if (resp->ret_code)
> +	if (len > resp_len)
> +		return;
> +
> +	/* Ensure that buffer_len leaves space for ret_code to be read back from memory */
> +	if (buf_len > len - sizeof(struct pmic_glink_hdr) - sizeof(u32))
> +		buf_len = len - sizeof(struct pmic_glink_hdr) - sizeof(u32);

I assume clipping the data is.. fine? I don't know the deep insides of
UCSI, but I'd assume this should always be plenty space for an ack

Konrad