linux-kernel - Re: [PATCH][ocfs2-next] ocfs2: ensure ret is set to zero before returning

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] [day] [month] [year] [list]

Date:   Thu, 8 Aug 2019 09:08:46 +0800
From:   Joseph Qi <joseph.qi@...ux.alibaba.com>
To:     Colin Ian King <colin.king@...onical.com>,
        Joseph Qi <jiangqi903@...il.com>,
        Mark Fasheh <mark@...heh.com>,
        Joel Becker <jlbec@...lplan.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        ocfs2-devel@....oracle.com,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][ocfs2-next] ocfs2: ensure ret is set to zero before
 returning



On 19/8/7 20:42, Colin Ian King wrote:
> On 07/08/2019 13:35, Joseph Qi wrote:
>>
>>
>> On 19/8/7 20:19, Colin King wrote:
>>> From: Colin Ian King <colin.king@...onical.com>
>>>
>>> A previous commit introduced a regression where variable ret was
>>> originally being set from the return from a call to function
>>> dlm_create_debugfs_subroot and this set was removed. Currently
>>> ret is now uninitialized if no alloction errors are found which
>>> may end up with a bogus check on ret < 0 on the 'leave:' return
>>> path.  Fix this by setting ret to zero on a successful execution
>>> path.
>>
>> Good catch.
>> Or shall we just initialize 'ret' at first?
> 
> Initialized ret first may not catch subsequent coding errors where error
> returns paths have not initialized ret, so my preference is when it is
> required and not before.
> 
Okay, looks good to me.
Reviewed-by: Joseph Qi <joseph.qi@...ux.alibaba.com>

>>
>>>
>>> Addresses-Coverity: ("Uninitialzed scalar variable")
> 
> Can this be fixed up when applied rather sending a V2?
>>
Currently ocfs2 patches are maintained in Andrew's mm tree.
So it depends on Andrew.

Thanks,
Joseph