Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes from Coverity Report (12/01/2017) #66

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

RanierV
Copy link

@RanierV RanierV commented Dec 1, 2017

Hi,
Can yours take a look.

Best regards,

Ranier Vilela

Fix Coverity report:
CID 200492 (nginx#1 of 1): Uninitialized scalar variable (UNINIT)2. uninit_use_in_call: Using uninitialized value sb.last when calling nxt_sendbuf_mem_coalesce. [show details]
CID 200488 (nginx#1 of 2): Dereference null return value (NULL_RETURNS)11. dereference: Dereferencing a pointer that might be null run_ctx.mem_pool when calling nxt_mp_destroy.
CID 200485 (nginx#1 of 1): Unused value (UNUSED_VALUE)assigned_value: Assigning value st_letter to state here, but that stored value is overwritten before it can be used.
CID 200484 (nginx#1 of 1): Uninitialized scalar variable (UNINIT)2. uninit_use_in_call: Using uninitialized value msg. Field msg.msg_flags is uninitialized when calling recvmsg
CID 200480 (nginx#2 of 2): Resource leak (RESOURCE_LEAK)22. leaked_storage: Variable p going out of scope leaks the storage it points to.
CID 200475 (nginx#1 of 1): Uninitialized scalar variable (UNINIT)2. uninit_use_in_call: Using uninitialized value sb.last when calling nxt_sendbuf_mem_coalesce.
CID 200471 (nginx#1 of 1): Uninitialized scalar variable (UNINIT)5. uninit_use_in_call: Using uninitialized value sb.last when calling nxt_sendbuf_mem_coalesce
@VBart VBart self-assigned this Dec 1, 2017
@@ -178,6 +178,12 @@ nxt_process_arguments(nxt_task_t *task, char **orig_argv, char ***orig_envp)
}

done:
if (p != NULL) {
nxt_free(p);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, I just saw this old PR around, and had a fast look at it. nxt_free(), as well as free(3), can handle NULL just fine. The conditionals are not necessary.

@@ -130,6 +125,11 @@ nxt_process_arguments(nxt_task_t *task, char **orig_argv, char ***orig_envp)
goto done;
}

p = nxt_malloc(strings_size);
Copy link
Contributor

@alejandro-colomar alejandro-colomar Sep 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you move p after the other goto done, you'll arrive at nxt_free() with an uninitialized pointer, which will result in Undefined Behavior.

That is, consider you jump to done from line 125 after this patch. You'll free p, which is uninitialized, and contains a random value. That will likely crash.

@alejandro-colomar
Copy link
Contributor

alejandro-colomar commented Oct 24, 2022

@raniervf There are some fixes that seem likely to be correct. Would you mind revisiting this pull request and fixing the issues I mentioned?

ac000

This comment was marked as duplicate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps not too surprisingly this code no longer exists. nxt_mp_create() is no longer called and was removed by

commit 349717fb90edaf50ae2846db7b72a2da4285541b
Author: Max Romanov <[email protected]>
Date:   Thu Jan 11 22:14:20 2018 +0300

    Changing relative php scripts paths to real ones.
    
    This is required to run phpMyAdmin.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... and as such is no longer flagged by coverity...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still looks valid, though likely has a pretty slim chance of triggering due to

#if (NXT_HAVE_LINUX_SENDFILE)                                                   
    .old_sendbuf = nxt_linux_event_conn_io_sendfile,                            
#elif (NXT_HAVE_FREEBSD_SENDFILE)                                               
    .old_sendbuf = nxt_freebsd_event_conn_io_sendfile,                          
#elif (NXT_HAVE_MACOSX_SENDFILE)                                                
    .old_sendbuf = nxt_macosx_event_conn_io_sendfile,                           
#elif (NXT_HAVE_SOLARIS_SENDFILEV)                                              
    .old_sendbuf = nxt_solaris_event_conn_io_sendfilev,                         
#elif (NXT_HAVE_AIX_SEND_FILE)                                                  
    .old_sendbuf = nxt_aix_event_conn_io_send_file,                             
#elif (NXT_HAVE_HPUX_SENDFILE)                                                  
    .old_sendbuf = nxt_hpux_event_conn_io_sendfile,                             
#else                                                                           
    .old_sendbuf = nxt_event_conn_io_sendbuf,                                   
#endif

and we only possibly take the problematic code path if we are using nxt_event_conn_io_sendbuf().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks valid, assuming that we can go

nxt_linux_event_conn_io_sendfile(() -> nxt_sendbuf_mem_coalesce()

and then

if (nxt_buf_is_mem(b)) {

can be false

@callahad
Copy link
Collaborator

Not entirely sure why this has lingered for so long.

@ac000 Do you think we can resolve this as-is this week, or should we close this and start anew with a fresh Coverity run?

Copy link
Member

@ac000 ac000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file was removed in commit 22c5100 and as such is no longer flagged by coverity.

Copy link
Member

@ac000 ac000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While that would certainly placate the analysers. I think a slightly larger cleanup is in order.

@callahad
Copy link
Collaborator

callahad commented Oct 14, 2024

With #1441 merged, do we still need this PR open?

@ac000
Copy link
Member

ac000 commented Oct 29, 2024

With #1441 merged, do we still need this PR open?

That was only one part of this.

Probably need to go through this PR and see what is still open in Coverity...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants