linux-kernel - Re: [PATCH 2/2] kunit: avoid memory leak on device register error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAq0SUk7nJ80rrMG+zeVi-XReVJ7sdWTAT9fmi4E+LpYAYa=OA@mail.gmail.com>
Date: Thu, 18 Apr 2024 14:18:59 -0300
From: Wander Lairson Costa <wander@...hat.com>
To: Markus Elfring <Markus.Elfring@....de>
Cc: kunit-dev@...glegroups.com, linux-kselftest@...r.kernel.org, 
	kernel-janitors@...r.kernel.org, Brendan Higgins <brendan.higgins@...ux.dev>, 
	David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] kunit: avoid memory leak on device register error

On Thu, Apr 18, 2024 at 12:24 PM Markus Elfring <Markus.Elfring@...de> wrote:
>
> > If the device register fails, free the allocated memory before
> > returning.
>
> * I suggest to use the word “registration” (instead of “register”)
>   in the commit message.
>
> * Would you like to add the tag “Fixes” accordingly?
>
>
> > +++ b/lib/kunit/device.c
> > @@ -131,6 +131,7 @@ static struct kunit_device *kunit_device_register_internal(struct kunit *test,
> >       err = device_register(&kunit_dev->dev);
> >       if (err) {
> >               put_device(&kunit_dev->dev);
> > +             kfree(kunit_dev);
> >               return ERR_PTR(err);
> >       }
>
> Common error handling code can be used instead
> if an additional label would be applied for a corresponding jump target.
>
> How do you think about to increase the application of scope-based resource management here?
>

I thought about that. But I think the code is simple enough (for now)
to not require an exit label.

> Regards,
> Markus
>