diff mbox series

[v2] keys: Use struct_size and size_add helper with alloc

Message ID 20220523014155.27840-1-guozihua@huawei.com (mailing list archive)
State New, archived
Headers show
Series [v2] keys: Use struct_size and size_add helper with alloc | expand

Commit Message

Guozihua (Scott) May 23, 2022, 1:41 a.m. UTC 
Use struct_size helper for calculating size of flexible struct, following
the best practice.

Reference: https://lore.kernel.org/all/CAHk-=wiGWjxs7EVUpccZEi6esvjpHJdgHQ=vtUeJ5crL62hx9A@mail.gmail.com/

Note: HASH_SIZE here is a SHA256_DIGEST_SIZE whoes value is 32, so
adding 1 should be fine here.

Signed-off-by: GUO Zihua <guozihua@huawei.com>

---

v2:
    Update the commit message, removing the part about "potential issue"
    following Jarkko's suggestion.

---
 security/keys/encrypted-keys/encrypted.c | 7 +++++--
 security/keys/user_defined.c             | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

Comments

Jarkko Sakkinen May 23, 2022, 8:17 p.m. UTC | #1 
On Mon, May 23, 2022 at 09:41:55AM +0800, GUO Zihua wrote:
> Use struct_size helper for calculating size of flexible struct, following
> the best practice.
> 
> Reference: https://lore.kernel.org/all/CAHk-=wiGWjxs7EVUpccZEi6esvjpHJdgHQ=vtUeJ5crL62hx9A@mail.gmail.com/
> 
> Note: HASH_SIZE here is a SHA256_DIGEST_SIZE whoes value is 32, so
> adding 1 should be fine here.
> 
> Signed-off-by: GUO Zihua <guozihua@huawei.com>

Instead

"""
Link: https://lore.kernel.org/all/CAHk-=wiGWjxs7EVUpccZEi6esvjpHJdgHQ=vtUeJ5crL62hx9A@mail.gmail.com/
Signed-off-by: GUO Zihua <guozihua@huawei.com>
"""

You should split this into two patches as said in
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes

Also these are bug fixes and the commit message does not contain
any description of the issue, e.g.

"""
When issuing

CF='-Wflexible-array-sizeof' make C=2 security/keys/encrypted-keys/encrypted.o

the following is observed:

security/keys/encrypted-keys/encrypted.c:670:28: warning: using sizeof on a flexible structure
security/keys/encrypted-keys/encrypted.c: note: in included file:
"""

And then explain why struct_size() addresses this issue, and provide
Fixes tag.

> 
> ---
> 
> v2:
>     Update the commit message, removing the part about "potential issue"
>     following Jarkko's suggestion.
> 
> ---
>  security/keys/encrypted-keys/encrypted.c | 7 +++++--
>  security/keys/user_defined.c             | 2 +-
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
> index e05cfc2e49ae..37349580e855 100644
> --- a/security/keys/encrypted-keys/encrypted.c
> +++ b/security/keys/encrypted-keys/encrypted.c
> @@ -613,6 +613,7 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key,
>  	long dlen;
>  	int i;
>  	int ret;
> +	size_t epayload_datalen = 0;
>  
>  	ret = kstrtol(datalen, 10, &dlen);
>  	if (ret < 0 || dlen < MIN_DATA_SIZE || dlen > MAX_DATA_SIZE)
> @@ -667,8 +668,10 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key,
>  	if (ret < 0)
>  		return ERR_PTR(ret);
>  
> -	epayload = kzalloc(sizeof(*epayload) + payload_datalen +
> -			   datablob_len + HASH_SIZE + 1, GFP_KERNEL);
> +	epayload_datalen = size_add(payload_datalen, datablob_len);
> +	epayload_datalen = size_add(epayload_datalen, HASH_SIZE + 1);
> +	epayload = kzalloc(struct_size(epayload, payload_data,
> +				epayload_datalen), GFP_KERNEL);
>  	if (!epayload)
>  		return ERR_PTR(-ENOMEM);
>  
> diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
> index 749e2a4dcb13..334fed36e9f3 100644
> --- a/security/keys/user_defined.c
> +++ b/security/keys/user_defined.c
> @@ -64,7 +64,7 @@ int user_preparse(struct key_preparsed_payload *prep)
>  	if (datalen <= 0 || datalen > 32767 || !prep->data)
>  		return -EINVAL;
>  
> -	upayload = kmalloc(sizeof(*upayload) + datalen, GFP_KERNEL);
> +	upayload = kmalloc(struct_size(upayload, data, datalen), GFP_KERNEL);
>  	if (!upayload)
>  		return -ENOMEM;
>  
> -- 
> 2.36.0
> 

BR, Jarkko
Guozihua (Scott) May 24, 2022, 1:50 a.m. UTC | #2 
Thanks for the feedback Jarkko.

Including Gustavo in the CC list as they are the maintainer of the 
corresponding KSPP issue.

On 2022/5/24 4:17, Jarkko Sakkinen wrote:
> On Mon, May 23, 2022 at 09:41:55AM +0800, GUO Zihua wrote:
>> Use struct_size helper for calculating size of flexible struct, following
>> the best practice.
>>
>> Reference: https://lore.kernel.org/all/CAHk-=wiGWjxs7EVUpccZEi6esvjpHJdgHQ=vtUeJ5crL62hx9A@mail.gmail.com/
>>
>> Note: HASH_SIZE here is a SHA256_DIGEST_SIZE whoes value is 32, so
>> adding 1 should be fine here.
>>
>> Signed-off-by: GUO Zihua <guozihua@huawei.com>
> 
> Instead
> 
> """
> Link: https://lore.kernel.org/all/CAHk-=wiGWjxs7EVUpccZEi6esvjpHJdgHQ=vtUeJ5crL62hx9A@mail.gmail.com/
> Signed-off-by: GUO Zihua <guozihua@huawei.com>
> """
> 
> You should split this into two patches as said in
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes
> 
> Also these are bug fixes and the commit message does not contain
> any description of the issue, e.g.

Thing is, it's not fixing any bug per se. It's a cleanup patch, updating 
codes calculating size of a variable-sized structure to the best 
practice. Should I still separate the patch in this case.
> 
> """
> When issuing
> 
> CF='-Wflexible-array-sizeof' make C=2 security/keys/encrypted-keys/encrypted.o
> 
> the following is observed:
> 
> security/keys/encrypted-keys/encrypted.c:670:28: warning: using sizeof on a flexible structure
> security/keys/encrypted-keys/encrypted.c: note: in included file:
> """
> 
> And then explain why struct_size() addresses this issue, and provide
> Fixes tag.

Struct_size is a macro that make use of sizeof under the hood. So 
struct_size does not actually address these warnings. However, the usage 
of struct_size for calculating size of variable-sized structure is 
suggested by Linus as the best pratice.
> 
>>
>> ---
>>
>> v2:
>>      Update the commit message, removing the part about "potential issue"
>>      following Jarkko's suggestion.
>>
>> ---
>>   security/keys/encrypted-keys/encrypted.c | 7 +++++--
>>   security/keys/user_defined.c             | 2 +-
>>   2 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
>> index e05cfc2e49ae..37349580e855 100644
>> --- a/security/keys/encrypted-keys/encrypted.c
>> +++ b/security/keys/encrypted-keys/encrypted.c
>> @@ -613,6 +613,7 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key,
>>   	long dlen;
>>   	int i;
>>   	int ret;
>> +	size_t epayload_datalen = 0;
>>   
>>   	ret = kstrtol(datalen, 10, &dlen);
>>   	if (ret < 0 || dlen < MIN_DATA_SIZE || dlen > MAX_DATA_SIZE)
>> @@ -667,8 +668,10 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key,
>>   	if (ret < 0)
>>   		return ERR_PTR(ret);
>>   
>> -	epayload = kzalloc(sizeof(*epayload) + payload_datalen +
>> -			   datablob_len + HASH_SIZE + 1, GFP_KERNEL);
>> +	epayload_datalen = size_add(payload_datalen, datablob_len);
>> +	epayload_datalen = size_add(epayload_datalen, HASH_SIZE + 1);
>> +	epayload = kzalloc(struct_size(epayload, payload_data,
>> +				epayload_datalen), GFP_KERNEL);
>>   	if (!epayload)
>>   		return ERR_PTR(-ENOMEM);
>>   
>> diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
>> index 749e2a4dcb13..334fed36e9f3 100644
>> --- a/security/keys/user_defined.c
>> +++ b/security/keys/user_defined.c
>> @@ -64,7 +64,7 @@ int user_preparse(struct key_preparsed_payload *prep)
>>   	if (datalen <= 0 || datalen > 32767 || !prep->data)
>>   		return -EINVAL;
>>   
>> -	upayload = kmalloc(sizeof(*upayload) + datalen, GFP_KERNEL);
>> +	upayload = kmalloc(struct_size(upayload, data, datalen), GFP_KERNEL);
>>   	if (!upayload)
>>   		return -ENOMEM;
>>   
>> -- 
>> 2.36.0
>>
> 
> BR, Jarkko
> .
diff mbox series

Patch

diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
index e05cfc2e49ae..37349580e855 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -613,6 +613,7 @@  static struct encrypted_key_payload *encrypted_key_alloc(struct key *key,
 	long dlen;
 	int i;
 	int ret;
+	size_t epayload_datalen = 0;
 
 	ret = kstrtol(datalen, 10, &dlen);
 	if (ret < 0 || dlen < MIN_DATA_SIZE || dlen > MAX_DATA_SIZE)
@@ -667,8 +668,10 @@  static struct encrypted_key_payload *encrypted_key_alloc(struct key *key,
 	if (ret < 0)
 		return ERR_PTR(ret);
 
-	epayload = kzalloc(sizeof(*epayload) + payload_datalen +
-			   datablob_len + HASH_SIZE + 1, GFP_KERNEL);
+	epayload_datalen = size_add(payload_datalen, datablob_len);
+	epayload_datalen = size_add(epayload_datalen, HASH_SIZE + 1);
+	epayload = kzalloc(struct_size(epayload, payload_data,
+				epayload_datalen), GFP_KERNEL);
 	if (!epayload)
 		return ERR_PTR(-ENOMEM);
 
diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
index 749e2a4dcb13..334fed36e9f3 100644
--- a/security/keys/user_defined.c
+++ b/security/keys/user_defined.c
@@ -64,7 +64,7 @@  int user_preparse(struct key_preparsed_payload *prep)
 	if (datalen <= 0 || datalen > 32767 || !prep->data)
 		return -EINVAL;
 
-	upayload = kmalloc(sizeof(*upayload) + datalen, GFP_KERNEL);
+	upayload = kmalloc(struct_size(upayload, data, datalen), GFP_KERNEL);
 	if (!upayload)
 		return -ENOMEM;