linux-kernel - Re: [PATCH] cpupower:Fix resource leaks in sysfs_get

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 for Android: free password hash cracker in your pocket

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

Message-ID: <d0420253c27c017d7617abcb75d900c82b68eda5.camel@kylinos.cn>
Date:   Fri, 14 Apr 2023 11:04:47 +0800
From:   Hao Zeng <zenghao@...inos.cn>
To:     Shuah Khan <skhan@...uxfoundation.org>
Cc:     trenn@...e.com, shuah@...nel.org, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpupower:Fix resource leaks in sysfs_get_enabled()

Dear Shuah
  Thank you for taking the time to reply to my email. 

On Thu, 2023-04-13 at 10:43 -0600, Shuah Khan wrote:
> On 4/12/23 22:46, Hao Zeng wrote:
> > The sysfs_get_enabled() opened file processor not closed,
> > may cause a file handle leak.
> > 
> 
> Please add information how you found this problem?
> 
> > Signed-off-by: Hao Zeng <zenghao@...inos.cn>
> > ---
> >   tools/power/cpupower/lib/powercap.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/power/cpupower/lib/powercap.c
> > b/tools/power/cpupower/lib/powercap.c
> > index 0ce29ee4c2e4..a39ee1c89679 100644
> > --- a/tools/power/cpupower/lib/powercap.c
> > +++ b/tools/power/cpupower/lib/powercap.c
> > @@ -51,7 +51,7 @@ static int sysfs_get_enabled(char *path, int
> > *mode)
> >                 close(fd);
> >                 return -1;
> >         }> -
> > +       close(fd);
> 
> The error path logic can be simplified with a goto to
> to handle the error path to close the file and return.
> 
> >         if (yes_no == '1') {
> >                 *mode = 1;
> >                 return 0;
> 
> This path that returns 0 can be simplified as well to do
> return just once, after error path handling is done with
> a goto.
  Ok, I will provide V2
> 
> Please send me v2 with the changes above with information
> on how you found the problem.
> 
  I didn't find this problem by testing, just by reading the code

> thanks,
> -- Shuah
> 
> thanks,
> -- Shuah