linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* hidp bug concerning ctrl_sk sock
@ 2012-12-06 21:04 Karl Relton
  0 siblings, 0 replies; 3+ messages in thread
From: Karl Relton @ 2012-12-06 21:04 UTC (permalink / raw)
  To: linux-bluetooth

With reference to bug https://bugzilla.kernel.org/show_bug.cgi?id=50541
it seems to me that the hidp driver has a problem in the hidp_session()
function.

The sock structure pointed to by ctrl_sk is being freed from under the
functions feet (as far as I can see), causing this function to crash.
Shouldn't a lock_sock or sock_hold be necessary to keep the sock
structure around until hidp_session has finished with it?



^ permalink raw reply	[flat|nested] 3+ messages in thread

* hidp bug concerning ctrl_sk sock
@ 2012-12-06 21:23 Karl Relton
  2012-12-11 20:05 ` Karl Relton
  0 siblings, 1 reply; 3+ messages in thread
From: Karl Relton @ 2012-12-06 21:23 UTC (permalink / raw)
  To: linux-bluetooth

With reference to bug https://bugzilla.kernel.org/show_bug.cgi?id=50541
it seems to me that the hidp driver has a problem in the hidp_session()
function.

The sock structure pointed to by ctrl_sk is being freed from under the
functions feet (as far as I can see), causing this function to crash.
Shouldn't a lock_sock or sock_hold be necessary to keep the sock
structure around until hidp_session has finished with it?




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: hidp bug concerning ctrl_sk sock
  2012-12-06 21:23 hidp bug concerning ctrl_sk sock Karl Relton
@ 2012-12-11 20:05 ` Karl Relton
  0 siblings, 0 replies; 3+ messages in thread
From: Karl Relton @ 2012-12-11 20:05 UTC (permalink / raw)
  To: linux-bluetooth

On Thu, 2012-12-06 at 21:23 +0000, Karl Relton wrote:
> With reference to bug https://bugzilla.kernel.org/show_bug.cgi?id=50541
> it seems to me that the hidp driver has a problem in the hidp_session()
> function.
> 
> The sock structure pointed to by ctrl_sk is being freed from under the
> functions feet (as far as I can see), causing this function to crash.
> Shouldn't a lock_sock or sock_hold be necessary to keep the sock
> structure around until hidp_session has finished with it?
> 
> 
A bit more testing, and a bit more accurate diagnosis to report. The
ctrl_sk is being orphaned in the l2cap bluetooth driver code. The
orphaning sets the sk_wq to null, leading to the OOPS in the
wait_event_timeout() call in hidp_session.

Is there some way of marking the sock as in use so that l2cap doesn't
orphan it straight away?




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-12-11 20:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-06 21:23 hidp bug concerning ctrl_sk sock Karl Relton
2012-12-11 20:05 ` Karl Relton
  -- strict thread matches above, loose matches on Subject: below --
2012-12-06 21:04 Karl Relton

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).