On 23/09/2021 14:22, Dan Carpenter wrote:

On Thu, Sep 23, 2021 at 09:26:51AM +0200, Krzysztof Kozlowski wrote:

quoted

On 23/09/2021 08:50, Dan Carpenter wrote:

quoted

This from static analysis inspired by CVE-2021-26708 where there was a
race condition because it didn't lock_sock(sk) before saving
"vsk->transport".  Here it is saving "llcp_sock->local" but the concept
is the same that it needs to take the lock first.

I think the difference between this llcp_sock code and above transport,
is lack of writer to llcp_sock->local with whom you could race.

Commits c0cfa2d8a788fcf4 and 6a2c0962105ae8ce causing the
multi-transport race show nicely assigns to vsk->transport when module
is unloaded.

Here however there is no writer to llcp_sock->local, except bind and
connect and their error paths. The readers which you modify here, have
to happen after bind/connect. You cannot have getsockopt() or release()
before bind/connect, can you? Unless you mean here the bind error path,
where someone calls getsockopt() in the middle of bind()? Is it even
possible?

I don't know if this is a real issue either.

Racing with bind would be harmless.  The local pointer would be NULL and
it would return harmlessly.  You would have to race with release and
have a third trying to release local devices.  (Again that might be
wild imagination.  It may not be possible).

Indeed. The code looks reasonable, though, so even if race is not really
reproducible:

Reviewed-by: Krzysztof Kozlowski <redacted>


Best regards,
Krzysztof