| Message ID | 20240123234731.work.358-kees@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | smb: Work around Clang __bdos() type confusion | expand |
On Wed, 24 Jan 2024 at 00:47, Kees Cook <keescook@chromium.org> wrote: > > Recent versions of Clang gets confused about the possible size of the > "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a > warning[1]: > > repro.c:126:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] > 126 | __write_overflow_field(p_size_field, size); > | ^ > > for this memset(): > > int len; > __le16 *user; > ... > len = ses->user_name ? strlen(ses->user_name) : 0; > user = kmalloc(2 + (len * 2), GFP_KERNEL); > ... > if (len) { > ... > } else { > memset(user, '\0', 2); > } > > While Clang works on this bug[2], switch to using a direct assignment, > which avoids memset() entirely which both simplifies the code and silences > the false positive warning. (Making "len" size_t also silences the > warning, but the direct assignment seems better.) > > Reported-by: Nathan Chancellor <nathan@kernel.org> > Closes: https://github.com/ClangBuiltLinux/linux/issues/1966 [1] > Link: https://github.com/llvm/llvm-project/issues/77813 [2] > Cc: Steve French <sfrench@samba.org> > Cc: Paulo Alcantara <pc@manguebit.com> > Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> > Cc: Shyam Prasad N <sprasad@microsoft.com> > Cc: Tom Talpey <tom@talpey.com> > Cc: linux-cifs@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > fs/smb/client/cifsencrypt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/smb/client/cifsencrypt.c b/fs/smb/client/cifsencrypt.c > index ef4c2e3c9fa6..6322f0f68a17 100644 > --- a/fs/smb/client/cifsencrypt.c > +++ b/fs/smb/client/cifsencrypt.c > @@ -572,7 +572,7 @@ static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash, > len = cifs_strtoUTF16(user, ses->user_name, len, nls_cp); > UniStrupr(user); > } else { > - memset(user, '\0', 2); > + *(u16 *)user = 0; Is 'user' guaranteed to be 16-bit aligned? > } > > rc = crypto_shash_update(ses->server->secmech.hmacmd5, > -- > 2.34.1 > >
On Thu, Jan 25, 2024 at 01:19:19PM +0100, Ard Biesheuvel wrote: > On Wed, 24 Jan 2024 at 00:47, Kees Cook <keescook@chromium.org> wrote: > > > > Recent versions of Clang gets confused about the possible size of the > > "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a > > warning[1]: > > > > repro.c:126:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] > > 126 | __write_overflow_field(p_size_field, size); > > | ^ > > > > for this memset(): > > > > int len; > > __le16 *user; > > ... > > len = ses->user_name ? strlen(ses->user_name) : 0; > > user = kmalloc(2 + (len * 2), GFP_KERNEL); > > ... > > if (len) { > > ... > > } else { > > memset(user, '\0', 2); > > } > > > > While Clang works on this bug[2], switch to using a direct assignment, > > which avoids memset() entirely which both simplifies the code and silences > > the false positive warning. (Making "len" size_t also silences the > > warning, but the direct assignment seems better.) > > > > Reported-by: Nathan Chancellor <nathan@kernel.org> > > Closes: https://github.com/ClangBuiltLinux/linux/issues/1966 [1] > > Link: https://github.com/llvm/llvm-project/issues/77813 [2] > > Cc: Steve French <sfrench@samba.org> > > Cc: Paulo Alcantara <pc@manguebit.com> > > Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> > > Cc: Shyam Prasad N <sprasad@microsoft.com> > > Cc: Tom Talpey <tom@talpey.com> > > Cc: linux-cifs@vger.kernel.org > > Cc: llvm@lists.linux.dev > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > fs/smb/client/cifsencrypt.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/smb/client/cifsencrypt.c b/fs/smb/client/cifsencrypt.c > > index ef4c2e3c9fa6..6322f0f68a17 100644 > > --- a/fs/smb/client/cifsencrypt.c > > +++ b/fs/smb/client/cifsencrypt.c > > @@ -572,7 +572,7 @@ static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash, > > len = cifs_strtoUTF16(user, ses->user_name, len, nls_cp); > > UniStrupr(user); > > } else { > > - memset(user, '\0', 2); > > + *(u16 *)user = 0; > > Is 'user' guaranteed to be 16-bit aligned? It's the first two bytes of a kmalloced address range, which I'm nearly certain will be sanely aligned, as those allocs are commonly used for holding structs, etc. -Kees
On Thu, 25 Jan 2024 at 19:00, Kees Cook <keescook@chromium.org> wrote: > > On Thu, Jan 25, 2024 at 01:19:19PM +0100, Ard Biesheuvel wrote: > > On Wed, 24 Jan 2024 at 00:47, Kees Cook <keescook@chromium.org> wrote: > > > > > > Recent versions of Clang gets confused about the possible size of the > > > "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a > > > warning[1]: > > > > > > repro.c:126:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] > > > 126 | __write_overflow_field(p_size_field, size); > > > | ^ > > > > > > for this memset(): > > > > > > int len; > > > __le16 *user; > > > ... > > > len = ses->user_name ? strlen(ses->user_name) : 0; > > > user = kmalloc(2 + (len * 2), GFP_KERNEL); > > > ... > > > if (len) { > > > ... > > > } else { > > > memset(user, '\0', 2); > > > } > > > > > > While Clang works on this bug[2], switch to using a direct assignment, > > > which avoids memset() entirely which both simplifies the code and silences > > > the false positive warning. (Making "len" size_t also silences the > > > warning, but the direct assignment seems better.) > > > > > > Reported-by: Nathan Chancellor <nathan@kernel.org> > > > Closes: https://github.com/ClangBuiltLinux/linux/issues/1966 [1] > > > Link: https://github.com/llvm/llvm-project/issues/77813 [2] > > > Cc: Steve French <sfrench@samba.org> > > > Cc: Paulo Alcantara <pc@manguebit.com> > > > Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> > > > Cc: Shyam Prasad N <sprasad@microsoft.com> > > > Cc: Tom Talpey <tom@talpey.com> > > > Cc: linux-cifs@vger.kernel.org > > > Cc: llvm@lists.linux.dev > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > --- > > > fs/smb/client/cifsencrypt.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/fs/smb/client/cifsencrypt.c b/fs/smb/client/cifsencrypt.c > > > index ef4c2e3c9fa6..6322f0f68a17 100644 > > > --- a/fs/smb/client/cifsencrypt.c > > > +++ b/fs/smb/client/cifsencrypt.c > > > @@ -572,7 +572,7 @@ static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash, > > > len = cifs_strtoUTF16(user, ses->user_name, len, nls_cp); > > > UniStrupr(user); > > > } else { > > > - memset(user, '\0', 2); > > > + *(u16 *)user = 0; > > > > Is 'user' guaranteed to be 16-bit aligned? > > It's the first two bytes of a kmalloced address range, which I'm nearly > certain will be sanely aligned, as those allocs are commonly used for > holding structs, etc. > Ah yes, this kmalloc() was carefully hidden in the commit log :-)
diff --git a/fs/smb/client/cifsencrypt.c b/fs/smb/client/cifsencrypt.c index ef4c2e3c9fa6..6322f0f68a17 100644 --- a/fs/smb/client/cifsencrypt.c +++ b/fs/smb/client/cifsencrypt.c @@ -572,7 +572,7 @@ static int calc_ntlmv2_hash(struct cifs_ses *ses, char *ntlmv2_hash, len = cifs_strtoUTF16(user, ses->user_name, len, nls_cp); UniStrupr(user); } else { - memset(user, '\0', 2); + *(u16 *)user = 0; } rc = crypto_shash_update(ses->server->secmech.hmacmd5,
Recent versions of Clang gets confused about the possible size of the "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a warning[1]: repro.c:126:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] 126 | __write_overflow_field(p_size_field, size); | ^ for this memset(): int len; __le16 *user; ... len = ses->user_name ? strlen(ses->user_name) : 0; user = kmalloc(2 + (len * 2), GFP_KERNEL); ... if (len) { ... } else { memset(user, '\0', 2); } While Clang works on this bug[2], switch to using a direct assignment, which avoids memset() entirely which both simplifies the code and silences the false positive warning. (Making "len" size_t also silences the warning, but the direct assignment seems better.) Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://github.com/ClangBuiltLinux/linux/issues/1966 [1] Link: https://github.com/llvm/llvm-project/issues/77813 [2] Cc: Steve French <sfrench@samba.org> Cc: Paulo Alcantara <pc@manguebit.com> Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> Cc: Shyam Prasad N <sprasad@microsoft.com> Cc: Tom Talpey <tom@talpey.com> Cc: linux-cifs@vger.kernel.org Cc: llvm@lists.linux.dev Signed-off-by: Kees Cook <keescook@chromium.org> --- fs/smb/client/cifsencrypt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)