diff options
| author | David Howells <dhowells@redhat.com> | 2020-02-06 13:55:01 +0000 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2020-02-11 04:35:55 -0800 |
| commit | 0f51165c22e425af2cb243b8a8e891f1ae9e34a8 (patch) | |
| tree | 60649f2bafa0f4a18686b5d092ed975fb31267f8 /include/linux/workqueue.h | |
| parent | 743823969080364a2ee04c20fa1d0411028554f5 (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/workqueue.h')
0 files changed, 0 insertions, 0 deletions
