From: Paulo Alcantara <pc@manguebit.org>
To: Bharath SM <bharathsm.hsk@gmail.com>,
linux-cifs@vger.kernel.org, smfrench@gmail.com
Cc: Bharath SM <bharathsm@microsoft.com>
Subject: Re: [PATCH 4/7] smb: add NULL check after kzalloc in cifsConvertToUTF16
Date: Thu, 19 Jun 2025 13:24:31 -0300 [thread overview]
Message-ID: <54184af46fa389c51312534fe05994b5@manguebit.org> (raw)
In-Reply-To: <20250619153538.1600500-4-bharathsm@microsoft.com>
Bharath SM <bharathsm.hsk@gmail.com> writes:
> Added a check to return -ENOMEM if kzalloc for wchar_to fails
>
> Signed-off-by: Bharath SM <bharathsm@microsoft.com>
> ---
> fs/smb/client/cifs_unicode.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/smb/client/cifs_unicode.c b/fs/smb/client/cifs_unicode.c
> index 4cc6e0896fad..7bc2268d6881 100644
> --- a/fs/smb/client/cifs_unicode.c
> +++ b/fs/smb/client/cifs_unicode.c
> @@ -466,6 +466,8 @@ cifsConvertToUTF16(__le16 *target, const char *source, int srclen,
> return cifs_strtoUTF16(target, source, PATH_MAX, cp);
>
> wchar_to = kzalloc(6, GFP_KERNEL);
> + if (wchar_to == NULL)
> + return -ENOMEM;
I wouldn't do that as there are several places that rely on
cifsConvertToUTF16() returning >= 0 and some other places that don't
even check its return value.
What about having it defined as
wchar_t wchar_to[3] = {};
and then getting rid of the memory allocation altogether?
next prev parent reply other threads:[~2025-06-19 16:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 15:35 [PATCH 1/7] smb: Use loff_t for directory position in cached_dirents Bharath SM
2025-06-19 15:35 ` [PATCH 2/7] smb: minor fix to use sizeof to initialize flags_string buffer Bharath SM
2025-06-19 16:06 ` Paulo Alcantara
2025-06-20 9:36 ` Shyam Prasad N
2025-06-19 15:35 ` [PATCH 3/7] smb: minor fix to use SMB2_NTLMV2_SESSKEY_SIZE for auth_key size Bharath SM
2025-06-19 16:08 ` Paulo Alcantara
2025-06-20 9:44 ` Shyam Prasad N
2025-06-19 15:35 ` [PATCH 4/7] smb: add NULL check after kzalloc in cifsConvertToUTF16 Bharath SM
2025-06-19 16:24 ` Paulo Alcantara [this message]
2025-06-20 15:04 ` Bharath SM
2025-06-20 9:44 ` Shyam Prasad N
2025-06-19 15:35 ` [PATCH 5/7] cifs: minor cleanup to remove unused permission bit macros Bharath SM
2025-06-19 15:35 ` [PATCH 6/7] smb: Fix potential divide-by-zero issue when iface_min_speed is 0 Bharath SM
2025-06-19 16:01 ` Paulo Alcantara
2025-06-20 15:04 ` Bharath SM
2025-06-20 9:49 ` Shyam Prasad N
2025-06-19 15:35 ` [PATCH 7/7] smb: Fix memory allocation and ACL handling in cifs_xattr_set Bharath SM
2025-06-19 15:57 ` Paulo Alcantara
2025-06-19 16:05 ` [PATCH 1/7] smb: Use loff_t for directory position in cached_dirents Paulo Alcantara
2025-06-20 9:34 ` Shyam Prasad N
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=54184af46fa389c51312534fe05994b5@manguebit.org \
--to=pc@manguebit.org \
--cc=bharathsm.hsk@gmail.com \
--cc=bharathsm@microsoft.com \
--cc=linux-cifs@vger.kernel.org \
--cc=smfrench@gmail.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