From: Colin Ian King <colin.king@canonical.com>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J . Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org, Dave Chinner <dchinner@redhat.com>,
Allison Collins <allison.henderson@oracle.com>,
Chandan Babu R <chandanrlinux@gmail.com>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfs: fix return of uninitialized value in variable error
Date: Fri, 9 Apr 2021 15:41:02 +0100 [thread overview]
Message-ID: <08de5ee4-28ca-cb33-7c6c-72f133d97b36@canonical.com> (raw)
In-Reply-To: <YHBkjihVv4+7D62Q@bfoster>
On 09/04/2021 15:28, Brian Foster wrote:
> On Fri, Apr 09, 2021 at 03:18:34PM +0100, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> A previous commit removed a call to xfs_attr3_leaf_read that
>> assigned an error return code to variable error. We now have
>> a few early error return paths to label 'out' that return
>> error if error is set; however error now is uninitialized
>> so potentially garbage is being returned. Fix this by setting
>> error to zero to restore the original behaviour where error
>> was zero at the label 'restart'.
>>
>> Addresses-Coverity: ("Uninitialized scalar variable")
>> Fixes: 07120f1abdff ("xfs: Add xfs_has_attr and subroutines")
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>> ---
>> fs/xfs/libxfs/xfs_attr.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/fs/xfs/libxfs/xfs_attr.c b/fs/xfs/libxfs/xfs_attr.c
>> index 472b3039eabb..902e5f7e6642 100644
>> --- a/fs/xfs/libxfs/xfs_attr.c
>> +++ b/fs/xfs/libxfs/xfs_attr.c
>> @@ -928,6 +928,7 @@ xfs_attr_node_addname(
>> * Search to see if name already exists, and get back a pointer
>> * to where it should go.
>> */
>> + error = 0;
>> retval = xfs_attr_node_hasname(args, &state);
>> if (retval != -ENOATTR && retval != -EEXIST)
>> goto out;
>
> I think it would be nicer to initialize at the top of the function as
> opposed to try and "preserve" historical behavior, but that nit aside:
I did think about that, but this fix does ensure it's zero'd for each
iteration rather than just the once, so it should catch any code changes
later on that may loop back to this point were error is non-zero.
>
> Reviewed-by: Brian Foster <bfoster@redhat.com>
>
>> --
>> 2.30.2
>>
>
next prev parent reply other threads:[~2021-04-09 14:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 14:18 Colin King
2021-04-09 14:28 ` Brian Foster
2021-04-09 14:41 ` Colin Ian King [this message]
2021-04-09 17:32 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=08de5ee4-28ca-cb33-7c6c-72f133d97b36@canonical.com \
--to=colin.king@canonical.com \
--cc=allison.henderson@oracle.com \
--cc=bfoster@redhat.com \
--cc=chandanrlinux@gmail.com \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®