From: Dan Carpenter <dan.carpenter@oracle.com>
To: Enzo Matsumiya <ematsumiya@suse.de>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>,
Steve French <sfrench@samba.org>, Paulo Alcantara <pc@cjr.nz>,
Ronnie Sahlberg <lsahlber@redhat.com>,
Shyam Prasad N <sprasad@microsoft.com>,
Tom Talpey <tom@talpey.com>,
kernel@collabora.com, kernel-janitors@vger.kernel.org,
linux-cifs@vger.kernel.org, samba-technical@lists.samba.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] cifs: remove initialization value
Date: Wed, 5 Oct 2022 17:58:14 +0300 [thread overview]
Message-ID: <Yz2bhrotBMO6JwPw@kadam> (raw)
In-Reply-To: <20221004142306.ysgh45nhgdo4z3ok@suse.de>
On Tue, Oct 04, 2022 at 11:23:06AM -0300, Enzo Matsumiya wrote:
> Hi Usama,
>
> On 10/04, Muhammad Usama Anjum wrote:
> > Don't initialize the rc as its value is being overwritten before its
> > use.
>
> Being bitten by an unitialized variable bug as recent as 2 days ago, I'd
> say this is a step backwards from the "best practices" POV.
Zero is a random bogus value.
How likely is it that zero is the correct value or a negative error code
is correct? There are probably a four to one ratio of error paths to
success paths in the kernel (100% made up statistic). But mostly
success paths end in "return 0;". So when you see a "return rc;" there
is probably less than one in ten chance that rc is potentially zero. So
there is an over 90% chance that zero is the wrong initializer to use.
Meanwhile what initializing things to bogus values does is it disables
static analysis checking for uninitialized value bugs. So it hides bugs
until the user hits them.
Disabling static analysis can make sense for a very complicated function
but it's not best practice in general.
On the other hand uninitialized memory is a source of security bugs.
There are two ways to prevent this: 1) Use static analysis. Currently
the GCC uninitialized variable warning is disabled because it is kind
of rubbish but there are other static analysis tools out there. 2) Use
the GCC extension to automatically initialize stack data to zero.
regards,
dan carpenter
next prev parent reply other threads:[~2022-10-05 15:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 6:23 [PATCH 1/2] cifs: remove initialization value Muhammad Usama Anjum
2022-10-04 6:23 ` [PATCH 2/2] cifs: check returned value for error Muhammad Usama Anjum
2022-10-04 19:01 ` Paulo Alcantara
2022-10-05 5:17 ` Muhammad Usama Anjum
2022-10-04 14:23 ` [PATCH 1/2] cifs: remove initialization value Enzo Matsumiya
2022-10-05 14:13 ` David Laight
2022-10-07 19:22 ` 'Enzo Matsumiya'
2022-10-05 14:58 ` Dan Carpenter [this message]
2022-10-04 18:59 ` Paulo Alcantara
2022-10-05 7:05 ` Steve French
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=Yz2bhrotBMO6JwPw@kadam \
--to=dan.carpenter@oracle.com \
--cc=ematsumiya@suse.de \
--cc=kernel-janitors@vger.kernel.org \
--cc=kernel@collabora.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsahlber@redhat.com \
--cc=pc@cjr.nz \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.com \
--cc=usama.anjum@collabora.com \
/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