From: Gustavo Padovan <gustavo@padovan.org>
To: Dean Jenkins <djenkins@mvista.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 3/4] Bluetooth: Avoid rfcomm_session_timeout using freed pointer
Date: Tue, 21 Aug 2012 15:56:06 -0300 [thread overview]
Message-ID: <20120821185606.GF17005@joana> (raw)
In-Reply-To: <1344710830-10301-4-git-send-email-djenkins@mvista.com>
Hi Dean,
* Dean Jenkins <djenkins@mvista.com> [2012-08-11 19:47:09 +0100]:
> rfcomm_session_timeout() protects the scenario of the remote
> Bluetooth device failing to send a DISC on the rfcomm control
> channel after the last data DLC channel has been closed.
>
> There is a race condition between the timer expiring causing
> rfcomm_session_timeout() to run and the rfcomm session being
> deleted. If the rfcomm session is deleted then
> rfcomm_session_timeout() would use a freed rfcomm session
> pointer resulting in a potential kernel crash or memory corruption.
> Note the timer is cleared before the rfcomm session is deleted
> by del_timer() so the circumstances for a failure to occur are
> as follows:
>
> rfcomm_session_timeout() needs to be executing before the
> del_timer() is called to clear the timer but
> rfcomm_session_timeout() needs to be delayed from using the
> rfcomm session pointer until after the session has been deleted.
> Therefore, there is a very small window of opportunity for failure.
>
> The solution is to use del_timer_sync() instead of del_timer()
> as this ensures that rfcomm_session_timeout() is not running
> when del_timer_sync() returns. This means that it is not
> possible for rfcomm_session_timeout() to run after the rfcomm
> session has been deleted.
>
> Signed-off-by: Dean Jenkins <djenkins@mvista.com>
> ---
> net/bluetooth/rfcomm/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 24d4d3c..c7921fd 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -264,8 +264,8 @@ static void rfcomm_session_clear_timer(struct rfcomm_session *s)
> {
> BT_DBG("session %p state %ld", s, s->state);
>
> - if (timer_pending(&s->timer))
> - del_timer(&s->timer);
> + /* ensure rfcomm_session_timeout() is not running past this point */
> + del_timer_sync(&s->timer);
I'm not happy of the idea of let the stack broken between patches 2 and 3
(this one). As you said if we use del_timer_sync() we don't need rfcnt here,
can you add this as a first patch, maybe? and after this continue to remove
the rest of the refcount code?
Gustavo
next prev parent reply other threads:[~2012-08-21 18:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-11 18:47 [PATCH 0/4] Bluetooth: Details of rfcomm fixes - remove session refcnt Dean Jenkins
2012-08-11 18:47 ` [PATCH 1/4] Bluetooth: Remove rfcomm " Dean Jenkins
2012-08-11 18:47 ` [PATCH 2/4] Bluetooth: Return rfcomm session pointers to avoid freed session Dean Jenkins
2012-08-11 18:47 ` [PATCH 3/4] Bluetooth: Avoid rfcomm_session_timeout using freed pointer Dean Jenkins
2012-08-21 18:56 ` Gustavo Padovan [this message]
2012-08-30 15:36 ` Dean Jenkins
2012-08-11 18:47 ` [PATCH 4/4] Bluetooth: On socket shutdown check rfcomm session and DLC exists Dean Jenkins
2012-08-21 18:50 ` Gustavo Padovan
2012-08-30 15:40 ` Dean Jenkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120821185606.GF17005@joana \
--to=gustavo@padovan.org \
--cc=djenkins@mvista.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).