summaryrefslogtreecommitdiff
path: root/sound
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2020-02-06 13:55:01 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-02-14 16:31:08 -0500
commit1b950f7aaea1fa5fceee99ee2fe2b114b2e23f34 (patch)
tree683535c23a01fb4e761e5d087b8327b996d3d8dd /sound
parent026d9148a8aceea7d27d165446f8bd4fb95c6f40 (diff)
rxrpc: Fix service call disconnection
[ Upstream commit b39a934ec72fa2b5a74123891f25273a38378b90 ] The recent patch that substituted a flag on an rxrpc_call for the connection pointer being NULL as an indication that a call was disconnected puts the set_bit in the wrong place for service calls. This is only a problem if a call is implicitly terminated by a new call coming in on the same connection channel instead of a terminating ACK packet. In such a case, rxrpc_input_implicit_end_call() calls __rxrpc_disconnect_call(), which is now (incorrectly) setting the disconnection bit, meaning that when rxrpc_release_call() is later called, it doesn't call rxrpc_disconnect_call() and so the call isn't removed from the peer's error distribution list and the list gets corrupted. KASAN finds the issue as an access after release on a call, but the position at which it occurs is confusing as it appears to be related to a different call (the call site is where the latter call is being removed from the error distribution list and either the next or pprev pointer points to a previously released call). Fix this by moving the setting of the flag from __rxrpc_disconnect_call() to rxrpc_disconnect_call() in the same place that the connection pointer was being cleared. Fixes: 5273a191dca6 ("rxrpc: Fix NULL pointer deref due to call->conn being cleared on disconnect") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'sound')
0 files changed, 0 insertions, 0 deletions