Comment 57 for bug 1165433

Fixed the bug title (so that the window of affected kernels is clear and it is clear that this is an issue both for raring and for saucy.

Also marked as confirmed, since the incomplete label was a bit weird at this point.

If I understand correctly the situation now is this

1) All kernels from 3.8.0 to 3.11.x are affected. 3.12 will most likely be fixed, unless something really unexpected happens with the 3.12 RC kernels and the fix eventually needs to be reverted.
2) The fix that is going into 3.12 RC1 would also apply cleanly to 3.11.x (and probably back to 3.8.x, possibly with very minor changes)
3) In spite of the fixing patches only touching rfcomm (that is anyway completely broken in 3.8.x to 3.11.x), they are considered too 'fat' for inclusion in the kernel stabilization series for 3.10.x and 3.11.x (I think that the kernel stabilization series for 3.9.x is terminated, so that 3.9 will not be fixed in anyway, and the kernel stabilization series for 3.8.x is in ubuntu's hands).
4) To provide a fix to 3.8.x to 3.11.x those who indicated the 3.12 fix as too fat for the stabilization series suggested a much 'thinner' approach based on BUG_ON. Unfortunately, when tried that approach proved not to fix the issue.

Now I wonder if the declaration of the proper fix as too fat for the stabilization series was in some way influenced by the wrong expectation to be able to count on a thinner fix.

At this point, either
- a proper 'thin' fix comes out soon suitable for the stabilization series and ubuntu imports it in raring and saucy's kernels
- ubuntu applies the proper 'fat' fix to its kernels even if it does not go to the stabilization series since in any case they only touch a subsystem that is currently utterly broken and to dangerous to use
- the bug remains unfixed in raring and saucy

In the last case, who is unaware may end up trying bluetooth DUN and experience a 'delayed' crash and data loss. The others will probably build a 3.8.x with the 'fat' fix on ppa and live happy.