| Message ID | 20240910111806.65945-1-r.smirnov@omp.ru |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] KEYS: prevent NULL pointer dereference in find_asymmetric_key() | expand |
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
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(-)