You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Result of a static analysis. No runtime information.
Code and Dependencies
In file: session.go, there is a possible channel blocking case.
In line 909, in function sessionPool:createMultiplexedSession, there is a send operation but no matching receive operation is found on that channel from any other goroutine.
The sequence starts from function createMultiplexedSession being invoked in separate goroutine.
Inside createMultiplexedSession, the code includes the following channel operation.
p.mayGetMultiplexedSession<-true
This line sends true to the mayGetMultiplexedSession channel to signal that the session request is processed. The intent seems to be to notify other parts of the code that it can now proceed to either handle the session (or manage the error).
The p.mayGetMultiplexedSession is an unbuffered channel.
So, the send operation will block until another goroutine receives from it. In the case of this code, there appears to be no guarantee that a corresponding receiver will be available to consume the message.
pool.mayGetMultiplexedSession is received. But it is inside a select statement. So, if the ctx.Done() becomes ready before the pool.mayGetMultiplexedSession, the function would return and the receive operation would not execute. As a a result the send operation would get blocked.
It is observed that all the other send operations on p.mayGetMultiplexedSession is done inside a select statement to check for the context.
Similar pattern can be applied to the current context to mitigate the issue.
Expected behavior
No runtime observation.
Actual behavior
No runtime observation.
Screenshots
No runtime observation.
Additional context
Sponsorship and Support:
This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.
The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.
The text was updated successfully, but these errors were encountered:
Client
Spanner
Environment
Result of a static analysis. No runtime information.
Code and Dependencies
In file: session.go, there is a possible channel blocking case.
In line 909, in function sessionPool:createMultiplexedSession, there is a send operation but no matching receive operation is found on that channel from any other goroutine.
The sequence starts from function
createMultiplexedSession
being invoked in separate goroutine.google-cloud-go/spanner/session.go
Line 752 in 79556c4
Inside
createMultiplexedSession
, the code includes the following channel operation.This line sends true to the
mayGetMultiplexedSession
channel to signal that the session request is processed. The intent seems to be to notify other parts of the code that it can now proceed to either handle the session (or manage the error).The
p.mayGetMultiplexedSession
is an unbuffered channel.google-cloud-go/spanner/session.go
Line 710 in 79556c4
So, the send operation will block until another goroutine receives from it. In the case of this code, there appears to be no guarantee that a corresponding receiver will be available to consume the message.
In the following code:
google-cloud-go/spanner/session.go
Line 762 in 79556c4
pool.mayGetMultiplexedSession
is received. But it is inside a select statement. So, if thectx.Done()
becomes ready before thepool.mayGetMultiplexedSession
, the function would return and the receive operation would not execute. As a a result the send operation would get blocked.It is observed that all the other send operations on
p.mayGetMultiplexedSession
is done inside a select statement to check for thecontext
.google-cloud-go/spanner/session.go
Line 916 in 79556c4
google-cloud-go/spanner/session.go
Line 938 in 79556c4
google-cloud-go/spanner/session.go
Line 981 in 79556c4
google-cloud-go/spanner/session.go
Line 990 in 79556c4
Similar pattern can be applied to the current context to mitigate the issue.
Expected behavior
No runtime observation.
Actual behavior
No runtime observation.
Screenshots
No runtime observation.
Additional context
Sponsorship and Support:
This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.
The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory and then manually triaging the results.
The text was updated successfully, but these errors were encountered: