From: Kees Cook <keescook@chromium.org>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Steve French <sfrench@samba.org>,
Paulo Alcantara <pc@manguebit.com>,
Ronnie Sahlberg <lsahlber@redhat.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Tom Talpey <tom@talpey.com>,
Christian Brauner <brauner@kernel.org>,
linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] smb: client: Fix -Wstringop-overflow issues
Date: Wed, 12 Jul 2023 17:01:23 -0700 [thread overview]
Message-ID: <202307121658.1C4E9C928D@keescook> (raw)
In-Reply-To: <ZK3h3+dHBGONHt+S@work>
On Tue, Jul 11, 2023 at 05:12:31PM -0600, Gustavo A. R. Silva wrote:
> pSMB->hdr.Protocol is an array of size 4 bytes, hence when the compiler
> analyzes this line of code
>
> parm_data = ((char *) &pSMB->hdr.Protocol) + offset;
>
> it legitimately complains about the fact that offset points outside the
> bounds of the array. Notice that the compiler gives priority to the object
> as an array, rather than merely the address of one more byte in a structure
> to wich offset should be added (which seems to be the actual intention of
> the original implementation).
>
> Fix this by explicitly instructing the compiler to treat the code as a
> sequence of bytes in struct smb_com_transaction2_spi_req, and not as an
> array accessed through pointer notation.
>
> Notice that ((char *)pSMB) + sizeof(pSMB->hdr.smb_buf_length) points to
> the same address as ((char *) &pSMB->hdr.Protocol), therefore this results
> in no differences in binary output.
>
> Fixes the following -Wstringop-overflow warnings when built s390
> architecture with defconfig (GCC 13):
> CC [M] fs/smb/client/cifssmb.o
> In function 'cifs_init_ace',
> inlined from 'posix_acl_to_cifs' at fs/smb/client/cifssmb.c:3046:3,
> inlined from 'cifs_do_set_acl' at fs/smb/client/cifssmb.c:3191:15:
> fs/smb/client/cifssmb.c:2987:31: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
> 2987 | cifs_ace->cifs_e_perm = local_ace->e_perm;
> | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
> In file included from fs/smb/client/cifssmb.c:27:
> fs/smb/client/cifspdu.h: In function 'cifs_do_set_acl':
> fs/smb/client/cifspdu.h:384:14: note: at offset [7, 11] into destination object 'Protocol' of size 4
> 384 | __u8 Protocol[4];
> | ^~~~~~~~
> In function 'cifs_init_ace',
> inlined from 'posix_acl_to_cifs' at fs/smb/client/cifssmb.c:3046:3,
> inlined from 'cifs_do_set_acl' at fs/smb/client/cifssmb.c:3191:15:
> fs/smb/client/cifssmb.c:2988:30: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
> 2988 | cifs_ace->cifs_e_tag = local_ace->e_tag;
> | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
> fs/smb/client/cifspdu.h: In function 'cifs_do_set_acl':
> fs/smb/client/cifspdu.h:384:14: note: at offset [6, 10] into destination object 'Protocol' of size 4
> 384 | __u8 Protocol[4];
> | ^~~~~~~~
>
> This helps with the ongoing efforts to globally enable
> -Wstringop-overflow.
>
> Link: https://github.com/KSPP/linux/issues/310
> Fixes: dc1af4c4b472 ("cifs: implement set acl method")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> fs/smb/client/cifssmb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/smb/client/cifssmb.c b/fs/smb/client/cifssmb.c
> index 19f7385abeec..9dee267f1893 100644
> --- a/fs/smb/client/cifssmb.c
> +++ b/fs/smb/client/cifssmb.c
> @@ -3184,7 +3184,7 @@ int cifs_do_set_acl(const unsigned int xid, struct cifs_tcon *tcon,
> param_offset = offsetof(struct smb_com_transaction2_spi_req,
> InformationLevel) - 4;
> offset = param_offset + params;
> - parm_data = ((char *) &pSMB->hdr.Protocol) + offset;
> + parm_data = ((char *)pSMB) + sizeof(pSMB->hdr.smb_buf_length) + offset;
> pSMB->ParameterOffset = cpu_to_le16(param_offset);
>
> /* convert to on the wire format for POSIX ACL */
This looks correct, though looking at this code I think some serious
comments are needed to describe _why_ these offsets are calculated the
way the are. The only dynamic part of parm_data is name_len, and could
just as easily be calculated as:
parm_data = pSMB->FileName + name_len;
which is MUCH more readable. But, yes, the above patch does result in
the same binary code.
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
prev parent reply other threads:[~2023-07-13 0:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 23:12 [PATCH] smb: client: Fix -Wstringop-overflow issues Gustavo A. R. Silva
2023-07-12 4:30 ` Steve French
2023-07-13 0:01 ` Kees Cook [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=202307121658.1C4E9C928D@keescook \
--to=keescook@chromium.org \
--cc=brauner@kernel.org \
--cc=gustavoars@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsahlber@redhat.com \
--cc=pc@manguebit.com \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
/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