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.

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.

In the following code:

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.

• google-cloud-go/spanner/session.go

  Line 916 in 79556c4

  case p.mayGetMultiplexedSession <- true:

• google-cloud-go/spanner/session.go

  Line 938 in 79556c4

  case p.mayGetMultiplexedSession <- true:

• google-cloud-go/spanner/session.go

  Line 981 in 79556c4

  case p.mayGetMultiplexedSession <- true:

• google-cloud-go/spanner/session.go

  Line 990 in 79556c4

  case p.mayGetMultiplexedSession <- true:

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.