HPCC-32939 Coverity jsocket accept socklen issue

[mckellyln]

Type of change:

• This change is a bug fix (non-breaking change which fixes an issue).
• This change is a new feature (non-breaking change which adds functionality).
• This change improves the code (refactor or other change that does not change the functionality)
• This change fixes warnings (the fix does not alter the functionality or the generated code)
• This change is a breaking change (fix or feature that will cause existing behavior to change).
• This change alters the query API (existing queries will have to be recompiled)

Checklist:

• My code follows the code style of this project.
  • My code does not create any new warnings from compiler, build system, or lint.
• The commit message is properly formatted and free of typos.
  • The commit message title makes sense in a changelog, by itself.
  • The commit is signed.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly, or...
  • I have created a JIRA ticket to update the documentation.
  • Any new interfaces or exported functions are appropriately commented.
• I have read the CONTRIBUTORS document.
• The change has been fully tested:
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have checked that this change does not introduce memory leaks.
  • I have used Valgrind or similar tools to check for potential issues.
• I have given due consideration to all of the following potential concerns:
  • Scalability
  • Performance
  • Security
  • Thread-safety
  • Cloud-compatibility
  • Premature optimization
  • Existing deployed queries will not be broken
  • This change fixes the problem, not just the symptom
  • The target branch of this pull request is appropriate for such a change.
• There are no similar instances of the same problem that should be addressed
  • I have addressed them here
  • I have raised JIRA issues to address them separately
• This is a user interface / front-end modification
  • I have tested my changes in multiple modern browsers
  • The component(s) render as expected

Smoketest:

• Send notifications about my Pull Request position in Smoketest queue.
• Test my draft Pull Request.

Testing:

[github-actions]

Jira Issue: https://hpccsystems.atlassian.net//browse/HPCC-32939

Jirabot Action Result:
Assigning user: [email protected]
Workflow Transition To: Merge Pending
Updated PR

[mckellyln]

I wonder if peerSockAddrLen used below in getSockAddrEndpoint() is also helped with this change ?

[jakesmith]

I think it would have been correct before either way, and accept() populates the addrLen with the actual size filled.

[jakesmith]

@mckellyln - looks good.

[ghalliday]

@mckellyln I don't really understand the logc of the code (see comment). There are also other places that seem to have the same problem.

[ghalliday]

@mckellyln I don't understand this code. The logic seems to be:
i) declare a union struct
ii) pass in the first member of the union
then call
getSockAddrEndpoint(peerSockAddr, peerSockAddrLen, *peerEp);
which either accesses the second or third elements of the union. That includes extracting the port - which as far as I can tell has not been initialised.....
There are also 3 other places in the same file that call getSockAddrEndpoint() with similar patterns/problems.

[mckellyln]

peerSockAddr is set in in the ::accept() call and should include the port.
In the other places u and ul should be set by the getpeername() or recvfrom() etc. calls.

[mckellyln]

I might be inclined to use ul = sizeof(u.sin) in these places as that is probably more typical.
The internal struct is like:

using sockaddr_t = union {
    sockaddr_storage ss;
    sockaddr_in6     sin6;
    sockaddr_in      sin;
    sockaddr         sa;
};

[mckellyln]

After some discussion we have decided to reject this issue and PR as invalid because there really is no memory overrun.