| Message ID | 20240910111806.65945-1-r.smirnov@omp.ru |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] KEYS: prevent NULL pointer dereference in find_asymmetric_key() | expand |
On Wed Sep 11, 2024 at 4:18 PM EEST, Jarkko Sakkinen wrote: > On Tue Sep 10, 2024 at 8:38 PM EEST, Sergey Shtylyov wrote: > > On 9/10/24 4:38 PM, Jarkko Sakkinen wrote: > > [...] > > > > >> In find_asymmetric_key(), if all NULLs are passed in id_{0,1,2} parameters > > >> the kernel will first emit WARN and then have an oops because id_2 gets > > >> dereferenced anyway. > > >> > > >> Found by Linux Verification Center (linuxtesting.org) with Svace static > > >> analysis tool. > > > > > > Weird, I recall that I've either sent a patch to address the same site > > > OR have commented a patch with similar reasoning. Well, it does not > > > matter, I think it this makes sense to me. > > > > > > You could further add to the motivation that given the panic_on_warn > > > kernel command-line parameter, it is for the best limit the scope and > > > use of the WARN-macro. > > > > I don't understand what you mean -- this version of the patch keeps > > the WARN_ON() call, it just moves that call, so that the duplicate id_{0,1,2} > > checks are avoided... > > I overlooked the code change (my bad sorry). Here's a better version of > the first paragraph: > > "find_asymmetric_keys() has nullity checks of id_0 and id_1 but ignores > validation for id_2. Check nullity also for id_2." > > Yep, and it changes no situation with WARN_ON() macro for better or > worse. It would logically separate issue to discuss and address so > as far as I'm concerned, with this clarification I think the change > makes sense to me. Actually explicitly stating that call paths leading to WARN_ON() invocation are intact by the commit (as a reminder for future). BR, Jarkko
On Thu Sep 12, 2024 at 4:51 PM EEST, Sergey Shtylyov wrote: > On 9/11/24 4:18 PM, Jarkko Sakkinen wrote: > [...] > > >>>> In find_asymmetric_key(), if all NULLs are passed in id_{0,1,2} parameters > >>>> the kernel will first emit WARN and then have an oops because id_2 gets > >>>> dereferenced anyway. > >>>> > >>>> Found by Linux Verification Center (linuxtesting.org) with Svace static > >>>> analysis tool. > >>> > >>> Weird, I recall that I've either sent a patch to address the same site > >>> OR have commented a patch with similar reasoning. Well, it does not > >>> matter, I think it this makes sense to me. > >>> > >>> You could further add to the motivation that given the panic_on_warn > >>> kernel command-line parameter, it is for the best limit the scope and > >>> use of the WARN-macro. > >> > >> I don't understand what you mean -- this version of the patch keeps > >> the WARN_ON() call, it just moves that call, so that the duplicate id_{0,1,2} > >> checks are avoided... > > > > I overlooked the code change (my bad sorry). Here's a better version of > > the first paragraph: > > > > "find_asymmetric_keys() has nullity checks of id_0 and id_1 but ignores > > validation for id_2. Check nullity also for id_2." > > Hm, what about WARN_ON(!id_0 && !id_1 && !id_2) -- it used to check all > the pointers, right? I think our variant was closer to reality... :-) Right (lazy validation, first null ignores rest) BR, Jarkko
On 9/12/24 5:27 PM, Jarkko Sakkinen wrote: [...] >>>>>> In find_asymmetric_key(), if all NULLs are passed in id_{0,1,2} parameters >>>>>> the kernel will first emit WARN and then have an oops because id_2 gets >>>>>> dereferenced anyway. >>>>>> >>>>>> Found by Linux Verification Center (linuxtesting.org) with Svace static >>>>>> analysis tool. >>>>> >>>>> Weird, I recall that I've either sent a patch to address the same site >>>>> OR have commented a patch with similar reasoning. Well, it does not >>>>> matter, I think it this makes sense to me. >>>>> >>>>> You could further add to the motivation that given the panic_on_warn >>>>> kernel command-line parameter, it is for the best limit the scope and >>>>> use of the WARN-macro. >>>> >>>> I don't understand what you mean -- this version of the patch keeps >>>> the WARN_ON() call, it just moves that call, so that the duplicate id_{0,1,2} >>>> checks are avoided... >>> >>> I overlooked the code change (my bad sorry). Here's a better version of >>> the first paragraph: >>> >>> "find_asymmetric_keys() has nullity checks of id_0 and id_1 but ignores >>> validation for id_2. Check nullity also for id_2." >> >> Hm, what about WARN_ON(!id_0 && !id_1 && !id_2) -- it used to check all >> the pointers, right? I think our variant was closer to reality... :-) > > Right (lazy validation, first null ignores rest) No, contrariwise: since we use && and !, first non-NULL would ignore the rest. > BR, Jarkko MBR, Sergey
On Thu Sep 12, 2024 at 8:36 PM EEST, Sergey Shtylyov wrote: > On 9/12/24 5:27 PM, Jarkko Sakkinen wrote: > [...] > > >>>>>> In find_asymmetric_key(), if all NULLs are passed in id_{0,1,2} parameters > >>>>>> the kernel will first emit WARN and then have an oops because id_2 gets > >>>>>> dereferenced anyway. > >>>>>> > >>>>>> Found by Linux Verification Center (linuxtesting.org) with Svace static > >>>>>> analysis tool. > >>>>> > >>>>> Weird, I recall that I've either sent a patch to address the same site > >>>>> OR have commented a patch with similar reasoning. Well, it does not > >>>>> matter, I think it this makes sense to me. > >>>>> > >>>>> You could further add to the motivation that given the panic_on_warn > >>>>> kernel command-line parameter, it is for the best limit the scope and > >>>>> use of the WARN-macro. > >>>> > >>>> I don't understand what you mean -- this version of the patch keeps > >>>> the WARN_ON() call, it just moves that call, so that the duplicate id_{0,1,2} > >>>> checks are avoided... > >>> > >>> I overlooked the code change (my bad sorry). Here's a better version of > >>> the first paragraph: > >>> > >>> "find_asymmetric_keys() has nullity checks of id_0 and id_1 but ignores > >>> validation for id_2. Check nullity also for id_2." > >> > >> Hm, what about WARN_ON(!id_0 && !id_1 && !id_2) -- it used to check all > >> the pointers, right? I think our variant was closer to reality... :-) > > > > Right (lazy validation, first null ignores rest) > > No, contrariwise: since we use && and !, first non-NULL would ignore the rest. Oops correct :-/ BR, Jarkko
On Wed Sep 11, 2024 at 5:45 PM EEST, Sergey Shtylyov wrote: > On 9/11/24 4:19 PM, Jarkko Sakkinen wrote: > > [...] > > >>>>> In find_asymmetric_key(), if all NULLs are passed in id_{0,1,2} parameters > >>>>> the kernel will first emit WARN and then have an oops because id_2 gets > >>>>> dereferenced anyway. > >>>>> > >>>>> Found by Linux Verification Center (linuxtesting.org) with Svace static > >>>>> analysis tool. > >>>> > >>>> Weird, I recall that I've either sent a patch to address the same site > >>>> OR have commented a patch with similar reasoning. Well, it does not > >>>> matter, I think it this makes sense to me. > >>>> > >>>> You could further add to the motivation that given the panic_on_warn > >>>> kernel command-line parameter, it is for the best limit the scope and > >>>> use of the WARN-macro. > >>> > >>> I don't understand what you mean -- this version of the patch keeps > >>> the WARN_ON() call, it just moves that call, so that the duplicate id_{0,1,2} > >>> checks are avoided... > >> > >> I overlooked the code change (my bad sorry). Here's a better version of > >> the first paragraph: > >> > >> "find_asymmetric_keys() has nullity checks of id_0 and id_1 but ignores > >> validation for id_2. Check nullity also for id_2." > >> > >> Yep, and it changes no situation with WARN_ON() macro for better or > >> worse. It would logically separate issue to discuss and address so > >> as far as I'm concerned, with this clarification I think the change > >> makes sense to me. > > > > Actually explicitly stating that call paths leading to WARN_ON() > > invocation are intact by the commit (as a reminder for future). > > OK... > Do you still think the Fixes tag should be dropped (and thus the > Reported-by tag would become unnecessary?)? I think we can keep them. BR, Jarkko
diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c index a5da8ccd353e..43af5fa510c0 100644 --- a/crypto/asymmetric_keys/asymmetric_type.c +++ b/crypto/asymmetric_keys/asymmetric_type.c @@ -60,17 +60,18 @@ struct key *find_asymmetric_key(struct key *keyring, char *req, *p; int len; - WARN_ON(!id_0 && !id_1 && !id_2); - if (id_0) { lookup = id_0->data; len = id_0->len; } else if (id_1) { lookup = id_1->data; len = id_1->len; - } else { + } else if (id_2) { lookup = id_2->data; len = id_2->len; + } else { + WARN_ON(1); + return ERR_PTR(-EINVAL); } /* Construct an identifier "id:<keyid>". */
In find_asymmetric_key(), if all NULLs are passed in id_{0,1,2} parameters the kernel will first emit WARN and then have an oops because id_2 gets dereferenced anyway. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 7d30198ee24f ("keys: X.509 public key issuer lookup without AKID") Suggested-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Roman Smirnov <r.smirnov@omp.ru> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> --- crypto/asymmetric_keys/asymmetric_type.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)