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

spanner: Fix a possible channel blocking issue #11126

Closed
openrefactorymunawar opened this issue Nov 13, 2024 · 0 comments · Fixed by #11131
Closed

spanner: Fix a possible channel blocking issue #11126

openrefactorymunawar opened this issue Nov 13, 2024 · 0 comments · Fixed by #11131
Assignees
Labels
api: spanner Issues related to the Spanner API. triage me I really want to be triaged.

Comments

@openrefactorymunawar
Copy link

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.

go pool.createMultiplexedSession()

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.

mayGetMultiplexedSession: make(chan bool),

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:

case <-pool.mayGetMultiplexedSession:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: spanner Issues related to the Spanner API. triage me I really want to be triaged.
Projects
None yet
2 participants