kzalloc() return should always be checked - notably in example code
where this may be seen as reference. On failure of allocation
livepatch_fix1_dummy_alloc() should return NULL.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
Problem was located with an experimental coccinelle script
Patch was compile tested with: x86_64_defconfig + FTRACE=y
FUNCTION_TRACER=y, EXPERT=y, LATENCYTOP=y, SAMPLES=y, SAMPLE_LIVEPATCH=y
(with some unrelated sparse warnings on symbols not being static)
Patch is against 4.20-rc6 (localversion-next is next-20181213)
samples/livepatch/livepatch-shadow-fix1.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/samples/livepatch/livepatch-shadow-fix1.c b/samples/livepatch/livepatch-shadow-fix1.c
index 49b1355..a0e8f04 100644
--- a/samples/livepatch/livepatch-shadow-fix1.c
+++ b/samples/livepatch/livepatch-shadow-fix1.c
@@ -89,6 +89,9 @@ struct dummy *livepatch_fix1_dummy_alloc(void)
* pointer to handle resource release.
*/
leak = kzalloc(sizeof(int), GFP_KERNEL);
+ if (!leak)
+ return NULL;
+
klp_shadow_alloc(d, SV_LEAK, sizeof(leak), GFP_KERNEL,
shadow_leak_ctor, leak);
--
2.1.4
kzalloc() return should be checked. On dummy_alloc() failing
in kzalloc() NULL should be returned.
Signed-off-by: Nicholas Mc Guire <[email protected]>
---
Problem was located with an experimental coccinelle script
Patch was compile tested with: x86_64_defconfig + FTRACE=y
FUNCTION_TRACER=y, EXPERT=y, LATENCYTOP=y, SAMPLES=y, SAMPLE_LIVEPATCH=y
(with a number of unrelated sparse warnings on symbols not being static)
Patch is against 4.20-rc6 (localversion-next is next-20181213)
samples/livepatch/livepatch-shadow-mod.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/samples/livepatch/livepatch-shadow-mod.c b/samples/livepatch/livepatch-shadow-mod.c
index 4c54b25..57d5cde 100644
--- a/samples/livepatch/livepatch-shadow-mod.c
+++ b/samples/livepatch/livepatch-shadow-mod.c
@@ -118,6 +118,8 @@ noinline struct dummy *dummy_alloc(void)
/* Oops, forgot to save leak! */
leak = kzalloc(sizeof(int), GFP_KERNEL);
+ if (!leak)
+ return NULL;
pr_info("%s: dummy @ %p, expires @ %lx\n",
__func__, d, d->jiffies_expire);
--
2.1.4
On Thu 2018-12-13 12:09:49, Nicholas Mc Guire wrote:
> kzalloc() return should always be checked - notably in example code
> where this may be seen as reference. On failure of allocation
> livepatch_fix1_dummy_alloc() should return NULL.
>
> Signed-off-by: Nicholas Mc Guire <[email protected]>
> ---
>
> Problem was located with an experimental coccinelle script
>
> Patch was compile tested with: x86_64_defconfig + FTRACE=y
> FUNCTION_TRACER=y, EXPERT=y, LATENCYTOP=y, SAMPLES=y, SAMPLE_LIVEPATCH=y
> (with some unrelated sparse warnings on symbols not being static)
>
> Patch is against 4.20-rc6 (localversion-next is next-20181213)
>
> samples/livepatch/livepatch-shadow-fix1.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/samples/livepatch/livepatch-shadow-fix1.c b/samples/livepatch/livepatch-shadow-fix1.c
> index 49b1355..a0e8f04 100644
> --- a/samples/livepatch/livepatch-shadow-fix1.c
> +++ b/samples/livepatch/livepatch-shadow-fix1.c
> @@ -89,6 +89,9 @@ struct dummy *livepatch_fix1_dummy_alloc(void)
> * pointer to handle resource release.
> */
> leak = kzalloc(sizeof(int), GFP_KERNEL);
> + if (!leak)
> + return NULL;
It should be:
if (!leak) {
kfree(d);
return NULL;
}
Note that The check is not strictly needed in this artificial
example because we never read/write any data there. But I agree
that we should add the check to promote the the right programming
patterns.
Best Regards,
Petr
On Thu 2018-12-13 12:09:50, Nicholas Mc Guire wrote:
> kzalloc() return should be checked. On dummy_alloc() failing
> in kzalloc() NULL should be returned.
>
> Signed-off-by: Nicholas Mc Guire <[email protected]>
> ---
>
> Problem was located with an experimental coccinelle script
>
> Patch was compile tested with: x86_64_defconfig + FTRACE=y
> FUNCTION_TRACER=y, EXPERT=y, LATENCYTOP=y, SAMPLES=y, SAMPLE_LIVEPATCH=y
> (with a number of unrelated sparse warnings on symbols not being static)
>
> Patch is against 4.20-rc6 (localversion-next is next-20181213)
>
> samples/livepatch/livepatch-shadow-mod.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/samples/livepatch/livepatch-shadow-mod.c b/samples/livepatch/livepatch-shadow-mod.c
> index 4c54b25..57d5cde 100644
> --- a/samples/livepatch/livepatch-shadow-mod.c
> +++ b/samples/livepatch/livepatch-shadow-mod.c
> @@ -118,6 +118,8 @@ noinline struct dummy *dummy_alloc(void)
>
> /* Oops, forgot to save leak! */
> leak = kzalloc(sizeof(int), GFP_KERNEL);
> + if (!leak)
> + return NULL;
The same comments apply here as for PATCH 1/2.
Best Regards,
Petr
On Thu, Dec 13, 2018 at 01:31:39PM +0100, Petr Mladek wrote:
> On Thu 2018-12-13 12:09:49, Nicholas Mc Guire wrote:
> > kzalloc() return should always be checked - notably in example code
> > where this may be seen as reference. On failure of allocation
> > livepatch_fix1_dummy_alloc() should return NULL.
> >
> > Signed-off-by: Nicholas Mc Guire <[email protected]>
> > ---
> >
> > Problem was located with an experimental coccinelle script
> >
> > Patch was compile tested with: x86_64_defconfig + FTRACE=y
> > FUNCTION_TRACER=y, EXPERT=y, LATENCYTOP=y, SAMPLES=y, SAMPLE_LIVEPATCH=y
> > (with some unrelated sparse warnings on symbols not being static)
> >
> > Patch is against 4.20-rc6 (localversion-next is next-20181213)
> >
> > samples/livepatch/livepatch-shadow-fix1.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/samples/livepatch/livepatch-shadow-fix1.c b/samples/livepatch/livepatch-shadow-fix1.c
> > index 49b1355..a0e8f04 100644
> > --- a/samples/livepatch/livepatch-shadow-fix1.c
> > +++ b/samples/livepatch/livepatch-shadow-fix1.c
> > @@ -89,6 +89,9 @@ struct dummy *livepatch_fix1_dummy_alloc(void)
> > * pointer to handle resource release.
> > */
> > leak = kzalloc(sizeof(int), GFP_KERNEL);
> > + if (!leak)
> > + return NULL;
>
> It should be:
>
> if (!leak) {
> kfree(d);
> return NULL;
> }
>
> Note that The check is not strictly needed in this artificial
> example because we never read/write any data there. But I agree
> that we should add the check to promote the the right programming
> patterns.
>
thanks for catching this !
will send a V2.
thx!
hofrat