Received-SPF: pass (google.com: domain of linux-kernel+bounces-29903-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <ea4117d5-bc70-4f6d-9fe4-e70e0cc47a6c@web.de>
Date: Thu, 18 Jan 2024 09:38:49 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] pstore/ram: Return directly after a failed kasprintf()
 call in ramoops_init_prz()
Content-Language: en-GB
To: Dan Carpenter <dan.carpenter@linaro.org>,
 linux-hardening@vger.kernel.org, kernel-janitors@vger.kernel.org,
 "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
 Joel Fernandes <joel@joelfernandes.org>, Kees Cook <keescook@chromium.org>,
 Tony Luck <tony.luck@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>, =?UTF-8?B?R8O8bnRlciBSw7Zjaw==?=
 <groeck@chromium.org>, Sai Prakash Ranjan
 <saiprakash.ranjan@codeaurora.org>, Kunwu Chan <chentao@kylinos.cn>
References: <644f44ad-7e2b-4a1a-bbd7-ccc79d479242@web.de>
 <26759e3b-ff74-4b04-b06f-4d68fbc5f606@moroto.mountain>
From: Markus Elfring <Markus.Elfring@web.de>
In-Reply-To: <26759e3b-ff74-4b04-b06f-4d68fbc5f606@moroto.mountain>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:mJ0dEA0NvLA=;dTB2kylOv6oJYX9V0c3EanhWlh8
 gHXqOviPoFcDqkCtG2CguXyQsV4A0BIYg/JSHreVhLsX/e2L2NQUrVr+0my9XK2ENWXbpGGOb
 6x44lIAGMlJbwYCKlejIvhptLS+dHiwKt63u2uI9MmGE94u/joRE+A2NGD6WL1uUVAunozIm8
 jTKFnD704vMciTL/j7schkkLf198LVe4oHFtqDUJdF4UzNE3Cs2X/S043T7ha8HNbAGkCM8/x
 tINTZF8WoxBlgCMYp85TDtH9Osjc4gJPGmIgFFOCXU7kTMXKMa6R3gmqi5YujL/92aYz2qVue
 jZYfk8me85L+iuZxGRnZr/MwZFXzj7f2ehpGae6aCZOWkEpcv6TBuyuQKoIALWz9olVGQvnu/
 izQAqe7HvJN1pi2OsbCb5SmxjK4oq/qN+vzTr6S/wYbJnlNssX58zeKcyqaO9Rpz4xDy2XaLD
 EI7xldmGrqUXAa8KAl2r44nN/IHQ/bb9T3Li8S9jUlTVqb7w/Cn9fJDUvuddHlEATY8ypKLIQ
 Le+GSvaJEZssfPjUbD6bhgrZ6k4xNmcXq5YtGNUpi7tTRSjnvWnjqZV4nt6rKKPXfo1mqlafR
 6oHAdvDAGLEp4MAG5OeJNis/AO1NZ5bog5fWTt0qJEuG3MwbHp3UB/5KTMyKxrWbY3YfFbZPA
 HOvvghQwygfha7Vkjcb7TVJyOkjec4xthjBB4sKGgLFwzxTsE4PqJ8ldD4Dd/lDC08aSxBbnY
 LrDFqS7rG1tKgbBI6qXfZb6tZib/eLNyYsgpCPVbUftd9C2sEEI+xkwHLeVhFcb8qF5YzZQ5r
 A4Y+CeAOP+B04/Pc80orfJ/ioqQMlTmo07gbmIkoIhwCAB+J3eJQRwGK0b3pXMwsC2+C7fjnO
 p1fUvpEWfIm1gHjNna+atKro1uWFhVXXCUOZm2jzU2250YlvdJdMxMzU3gIZUfoNELVnkJJDj
 enbmkw==

>> The result from a call of the function =E2=80=9Ckasprintf=E2=80=9D was =
passed to
>> a subsequent function call without checking for a null pointer before
>> (according to a memory allocation failure).
>> This issue was detected by using the Coccinelle software.
=E2=80=A6
>> +++ b/fs/pstore/ram.c
>> @@ -595,6 +595,9 @@ static int ramoops_init_prz(const char *name,
>>  	}
>>
>>  	label =3D kasprintf(GFP_KERNEL, "ramoops:%s", name);
>> +	if (!label)
>> +		return -ENOMEM;
>> +
>>  	*prz =3D persistent_ram_new(*paddr, sz, sig, &cxt->ecc_info,
>>  				  cxt->memtype, PRZ_FLAG_ZAP_OLD, label);
>>  	kfree(label);
>
> This patch is fine as a clean up, but I think it's useful to say that
> if you pass a NULL label to persistent_ram_new() then it will return
> an error.
=E2=80=A6

Will it become helpful to annotate the corresponding function input parame=
ter
for null pointer tolerance anyhow?

Regards,
Markus