[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <930c76ab-89a9-3b03-7436-50bfb5696d0c@talpey.com>
Date: Mon, 19 Jun 2023 08:26:29 -0400
From: Tom Talpey <tom@...pey.com>
To: Arnd Bergmann <arnd@...nel.org>,
Namjae Jeon <linkinjeon@...nel.org>,
Steve French <sfrench@...ba.org>
Cc: Arnd Bergmann <arnd@...db.de>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>,
Christian Brauner <brauner@...nel.org>,
Ronnie Sahlberg <lsahlber@...hat.com>,
Hyunchul Lee <hyc.lee@...il.com>, linux-cifs@...r.kernel.org,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] [v2] smb: avoid field overflow warning
On 6/19/2023 4:19 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@...db.de>
>
> clang warns about a possible field overflow in a memcpy:
>
> In file included from fs/smb/server/smb_common.c:7:
> include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> __write_overflow_field(p_size_field, size);
>
> It appears to interpret the "&out[baselen + 4]" as referring to a single
> byte of the character array, while the equivalen "out + baselen + 4" is
> seen as an offset into the array.
>
> I don't see that kind of warning elsewhere, so just go with the simple
> rework.
>
> Fixes: e2f34481b24db ("cifsd: add server-side procedures for SMB3")
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> ----
> v2: fix typo in array length, and make sure it still addresses the warning
> ---
> fs/smb/server/smb_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/smb/server/smb_common.c b/fs/smb/server/smb_common.c
> index a7e81067bc991..39c6c8d7d0623 100644
> --- a/fs/smb/server/smb_common.c
> +++ b/fs/smb/server/smb_common.c
> @@ -536,7 +536,7 @@ int ksmbd_extract_shortname(struct ksmbd_conn *conn, const char *longname,
> out[baselen + 3] = PERIOD;
>
> if (dot_present)
> - memcpy(&out[baselen + 4], extension, 4);
> + memcpy(out + baselen + 4, extension, 4);
> else
> out[baselen + 4] = '\0';
> smbConvertToUTF16((__le16 *)shortname, out, PATH_MAX,
It'd be really confusing to have the other two out[baselen + foo] = bar
in the lines above and below.
Can this be fixed more clearly with a new pointer, like
char *q = &out[baselen + 4];
memcpy(q, extension, 4);
??
Tom.
Powered by blists - more mailing lists