Re: [PATCH v2 1/3] smb/server: fix signing when a response uses more than one iov

Andy Shevchenko <[email protected]> Thu, 16 Jul 2026 23:24:25 +0300
Newsgroups org.kernel.vger.linux-cifs
Organization Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo
Message-ID <[email protected]>
On Thu, Jul 16, 2026 at 12:11:54AM +0000, ChenXiaoSong wrote:

> Some SMB responses keep their data in another buffer. The SMB header
> and the data are then in different iovs.
> 
> The old code only handled this for SMB2 READ. For other commands, it
> signed only the last iov. QUERY_INFO and CHANGE_NOTIFY can also use
> another iov for their data. Their SMB header was not signed, so Windows
> will client rejected the response.
> 
> Find the iov that starts with the current SMB header. Sign this iov and
> all iovs after it.

...

> +static struct kvec *smb2_get_sign_rsp_iov(struct ksmbd_work *work,
> +					   struct smb2_hdr *hdr, int *n_vec)
> +{

> +	int i;

This is not addressed, why?

> +	/*
> +	 * iov[0] has the RFC1002 message length. It is not part of the SMB2
> +	 * message, so do not sign it.
> +	 */
> +	for (i = 1; i <= work->iov_idx; i++) {
> +		if (work->iov[i].iov_base == hdr) {
> +			*n_vec = work->iov_idx - i + 1;
> +			return &work->iov[i];
> +		}
> +	}
> +
> +	WARN_ON_ONCE(work->iov_idx < 1 ||
> +		     work->iov[work->iov_idx].iov_base != hdr);

The second part of this check is basically always true. What's the point?

> +	*n_vec = 1;
> +	return &work->iov[work->iov_idx];
> +}

-- 
With Best Regards,
Andy Shevchenko