summaryrefslogtreecommitdiff
path: root/include/linux/reset-controller.h
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-11 04:35:55 -0800
commit0f51165c22e425af2cb243b8a8e891f1ae9e34a8 (patch)
tree60649f2bafa0f4a18686b5d092ed975fb31267f8 /include/linux/reset-controller.h
parent743823969080364a2ee04c20fa1d0411028554f5 (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 'include/linux/reset-controller.h')
0 files changed, 0 insertions, 0 deletions