Don't initialize the rc as its value is being overwritten before its
use.
Signed-off-by: Muhammad Usama Anjum <[email protected]>
---
fs/cifs/smb2pdu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 0600f0a07628..2bf43c892ae6 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -879,7 +879,7 @@ SMB2_negotiate(const unsigned int xid,
struct smb2_negotiate_rsp *rsp;
struct kvec iov[1];
struct kvec rsp_iov;
- int rc = 0;
+ int rc;
int resp_buftype;
int blob_offset, blob_length;
char *security_blob;
--
2.30.2
smb311_decode_neg_context() can return error. Its return value should be
checked for errors.
Signed-off-by: Muhammad Usama Anjum <[email protected]>
---
fs/cifs/smb2pdu.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 2bf43c892ae6..c6e37352dbe1 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1089,11 +1089,14 @@ SMB2_negotiate(const unsigned int xid,
server->signing_algorithm = SIGNING_ALG_AES_CMAC;
server->signing_negotiated = false;
- if (rsp->NegotiateContextCount)
+ if (rsp->NegotiateContextCount) {
rc = smb311_decode_neg_context(rsp, server,
rsp_iov.iov_len);
- else
+ if (rc)
+ goto neg_exit;
+ } else {
cifs_server_dbg(VFS, "Missing expected negotiate contexts\n");
+ }
/*
* Some servers will not send a SMB2_SIGNING_CAPABILITIES context response (*),
--
2.30.2
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.
>Signed-off-by: Muhammad Usama Anjum <[email protected]>
>---
> fs/cifs/smb2pdu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
>index 0600f0a07628..2bf43c892ae6 100644
>--- a/fs/cifs/smb2pdu.c
>+++ b/fs/cifs/smb2pdu.c
>@@ -879,7 +879,7 @@ SMB2_negotiate(const unsigned int xid,
> struct smb2_negotiate_rsp *rsp;
> struct kvec iov[1];
> struct kvec rsp_iov;
>- int rc = 0;
>+ int rc;
> int resp_buftype;
> int blob_offset, blob_length;
> char *security_blob;
>--
>2.30.2
Cheers,
Enzo
Muhammad Usama Anjum <[email protected]> writes:
> Don't initialize the rc as its value is being overwritten before its
> use.
>
> Signed-off-by: Muhammad Usama Anjum <[email protected]>
> ---
> fs/cifs/smb2pdu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
Muhammad Usama Anjum <[email protected]> writes:
> smb311_decode_neg_context() can return error. Its return value should be
> checked for errors.
>
> Signed-off-by: Muhammad Usama Anjum <[email protected]>
> ---
> fs/cifs/smb2pdu.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 2bf43c892ae6..c6e37352dbe1 100644
This patch doesn't apply in Steve's for-next branch[1]. If it still
makes sense, please rebase and resend.
[1] git://git.samba.org/sfrench/cifs-2.6.git
On 10/5/22 12:01 AM, Paulo Alcantara wrote:
> Muhammad Usama Anjum <[email protected]> writes:
>
>> smb311_decode_neg_context() can return error. Its return value should be
>> checked for errors.
>>
>> Signed-off-by: Muhammad Usama Anjum <[email protected]>
>> ---
>> fs/cifs/smb2pdu.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
>> index 2bf43c892ae6..c6e37352dbe1 100644
>
> This patch doesn't apply in Steve's for-next branch[1]. If it still
> makes sense, please rebase and resend.
>
> [1] git://git.samba.org/sfrench/cifs-2.6.git
I've just applied on the latest next next-20221004 tag. This patch
doesn't apply. It seems some other patch has merged and this patch isn't
needed.
Can you apply only the first patch "[PATCH 1/2] cifs: remove
initialization value" from this series? Or should I send that only as v2?
merged into cifs-2.6.git for-next
On Tue, Oct 4, 2022 at 2:09 PM Paulo Alcantara <[email protected]> wrote:
>
> Muhammad Usama Anjum <[email protected]> writes:
>
> > Don't initialize the rc as its value is being overwritten before its
> > use.
> >
> > Signed-off-by: Muhammad Usama Anjum <[email protected]>
> > ---
> > fs/cifs/smb2pdu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
--
Thanks,
Steve
From: Enzo Matsumiya
> Sent: 04 October 2022 15:23
>
> 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.
Depends on your POV.
If you don't initialise locals there is a fair chance that the
compiler will detect buggy code.
If you initialise them you get well defined behaviour - but
the compiler won't find bugs for you.
Mostly the kernel is in the first camp.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
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
On 10/05, David Laight wrote:
>From: Enzo Matsumiya
>> Sent: 04 October 2022 15:23
>>
>> 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.
>
>Depends on your POV.
My POV was, considering "unitialized variables" is a _whole_ class of
security bugs, a patch to specifically deinitialize a variable is pretty
much like saying "let's leave this to chance".
https://cwe.mitre.org/data/definitions/457.html
>If you don't initialise locals there is a fair chance that the
>compiler will detect buggy code.
>
>If you initialise them you get well defined behaviour - but
>the compiler won't find bugs for you.
>
>Mostly the kernel is in the first camp.
My money is on the smaller unfair chances that the compiler cannot catch
even the smallest bit of complexity of uninitialized use.
Also, initializing something to 0/NULL will, most of the time, if at all,
be "just" a bug, whereas an uninitialized variable bug might turn into a
security bug and even go unnoticed for years.
Anyway, this patch got merged and I seem to be alone with this
concern...
> David
Cheers,
Enzo