Hi Mat,
> When the last RFCOMM data channel is closed, a timer is normally set
> up to disconnect the control channel at a later time. If the control
> channel disconnect command is sent with the timer pending, the timer
> needs to be cancelled.
>
> If the timer is not cancelled in this situation, the reference
> counting logic for the RFCOMM session does not work correctly when the
> remote device closes the L2CAP connection. The session is freed at
> the wrong time, leading to a kernel panic.
>
> Signed-off-by: Mat Martineau <mathewm@xxxxxxxxxxxxxx>
> ---
> net/bluetooth/rfcomm/core.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 4e32e18..2d28dfe 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1146,6 +1146,7 @@ static int rfcomm_recv_ua(struct rfcomm_session *s, u8 dlci)
> if (list_empty(&s->dlcs)) {
> s->state = BT_DISCONN;
> rfcomm_send_disc(s, 0);
> + rfcomm_session_clear_timer(s);
> }
I am not 100% convinced that this is correct, but going through the code
for over an hour I could not come up with a case where this would cause
problems. It is just a feeling and with RFCOMM that could be just a
bogus feeling ;)
Acked-by: Marcel Holtmann <marcel@xxxxxxxxxxxx>
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
