linux-kernel - Re: [PATCH v1] platform/x86/dell/dell-rbtn: Fix resources leaking on error path

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: <20230612205839.wxo2h2ahqcdo73rc@pali>
Date:   Mon, 12 Jun 2023 22:58:39 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...el.com>
Cc:     Michal Wilczynski <michal.wilczynski@...el.com>,
        linux-acpi@...r.kernel.org, rafael@...nel.org,
        ilpo.jarvinen@...ux.intel.com, hdegoede@...hat.com,
        markgross@...nel.org, fengguang.wu@...el.com,
        dvhart@...ux.intel.com, platform-driver-x86@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] platform/x86/dell/dell-rbtn: Fix resources leaking on
 error path

On Monday 12 June 2023 23:52:30 Andy Shevchenko wrote:
> On Mon, Jun 12, 2023 at 07:52:05PM +0200, Pali Rohár wrote:
> > On Monday 12 June 2023 12:02:50 Michal Wilczynski wrote:
> > > Currently rbtn_add() in case of failure is leaking resources. Fix this
> > > by adding a proper rollback. While at it, remove unnecessary assignment
> > > of NULL to device->driver_data and unnecessary whitespace, plus add a
> > > break for the default case in a switch.
> 
> ...
> 
> > Hello! I'm looking at rbtn_add() function and there is also code:
> > 
> > 	rbtn_data = devm_kzalloc(&device->dev, sizeof(*rbtn_data), GFP_KERNEL);
> > 	if (!rbtn_data)
> > 		return -ENOMEM;
> > 
> > which is called after rbtn_acquire(). So it looks like when kzalloc
> > fails then there is another leak...
> 
> Side note: In that case we would need a devm wrapper on acquire call.

Does it makes sense to invest time and more resources for these fixes?
Driver is not used on new Dell machines, so I would not expect new
users (instead less users, if they start upgrading HW to new Dell
machines).

Simple fix for this issue: Just move devm_kzalloc() call before
rbtn_acquire(true). And call cleanup rbtn_acquire(false) exactly like
Michal did in this patch.

I think that this should be enough, should cover all failure paths and
does not require to introduce new code or new design, which should be
properly tested for no regression.

What do you think?