Received-SPF: pass (google.com: domain of linux-crypto+bounces-2736-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 19 Mar 2024 01:39:00 +0200
Message-Id: <CZX9T3TU6YU0.3JE9M7M3ENUE0@kernel.org>
Cc: <keyrings@vger.kernel.org>, <linux-crypto@vger.kernel.org>,
 <linux-kernel@vger.kernel.org>, <lvc-project@linuxtesting.org>, "Sergey
 Shtylyov" <s.shtylyov@omp.ru>
Subject: Re: [PATCH] KEYS: prevent NULL pointer dereference in
 find_asymmetric_key()
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Roman Smirnov" <r.smirnov@omp.ru>, "David Howells"
 <dhowells@redhat.com>, "Herbert Xu" <herbert@gondor.apana.org.au>, "David
 S. Miller" <davem@davemloft.net>, "Andrew Zaborowski"
 <andrew.zaborowski@intel.com>
References: <20240315103320.18754-1-r.smirnov@omp.ru>
In-Reply-To: <20240315103320.18754-1-r.smirnov@omp.ru>

On Fri Mar 15, 2024 at 12:33 PM EET, Roman Smirnov wrote:
> With the current code, in case all NULLs are passed in id_{0,1,2},

"current code" is not unambigious reference of any part of the kernel
tree. Please just write down the function name instead.

> the kernel will first print out a WARNING and then have an oops
> because id_2 gets dereferenced anyway.

Would be more exact":

s/print out a WARNING/emit WARN/

> Note that WARN_ON() is also considered harmful by Greg Kroah-
> Hartman since it causes the Android kernels to panic as they
> get booted with the panic_on_warn option.

Despite full respect to Greg, and agreeing what he had said about
the topic (which you are lacking lore link meaning that in all
cases the current description is incomplete), the only thing that
should be documented should be that since WARN_ON() can emit
panic when panic_on_warn is set in the *kernel command-line*
(not "option") this condition should be relaxed.

>
> Found by Linux Verification Center (linuxtesting.org) with Svace.

I'm not sure if this should be part of the commit message.

>
> Fixes: 7d30198ee24f ("keys: X.509 public key issuer lookup without AKID")
> Suggested-by: Sergey Shtylyov <s.shtylyov@omp.ru>

Should be reported-by.

> Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
> ---
>  crypto/asymmetric_keys/asymmetric_type.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric=
_keys/asymmetric_type.c
> index a5da8ccd353e..f5cbd6ff14e2 100644
> --- a/crypto/asymmetric_keys/asymmetric_type.c
> +++ b/crypto/asymmetric_keys/asymmetric_type.c
> @@ -60,17 +60,17 @@ struct key *find_asymmetric_key(struct key *keyring,
>  	char *req, *p;
>  	int len;
> =20
> -	WARN_ON(!id_0 && !id_1 && !id_2);
> -

Weird, I recall discussing about this issue in the past. Unfortunately
could not find the thread from lore.

Anyway I agree with the code change.

>  	if (id_0) {
>  		lookup =3D id_0->data;
>  		len =3D id_0->len;
>  	} else if (id_1) {
>  		lookup =3D id_1->data;
>  		len =3D id_1->len;
> -	} else {
> +	} else if (id_2) {
>  		lookup =3D id_2->data;
>  		len =3D id_2->len;
> +	} else {
> +		return ERR_PTR(-EINVAL);
>  	}
> =20
>  	/* Construct an identifier "id:<keyid>". */


BR, Jarkko