Message ID | 20220523014155.27840-1-guozihua@huawei.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [v2] keys: Use struct_size and size_add helper with alloc | expand |
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
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 --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;
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(-)