lwn.git/net/bluetooth/rfcomm/core.c, branch v3.14.48

Bluetooth: Avoid use of session socket after the session gets freed

2014-09-17T16:19:23+00:00

commit 32333edb82fb2009980eefc5518100068147ab82 upstream. The commits 08c30aca9e698faddebd34f81e1196295f9dc063 "Bluetooth: Remove RFCOMM session refcnt" and 8ff52f7d04d9cc31f1e81dcf9a2ba6335ed34905 "Bluetooth: Return RFCOMM session ptrs to avoid freed session" allow rfcomm_recv_ua and rfcomm_session_close to delete the session (and free the corresponding socket) and propagate NULL session pointer to the upper callers. Additional fix is required to terminate the loop in rfcomm_process_rx function to avoid use of freed 'sk' memory. The issue is only reproducible with kernel option CONFIG_PAGE_POISONING enabled making freed memory being changed and filled up with fixed char value used to unmask use-after-free issues. Signed-off-by: Vignesh Raman Signed-off-by: Vitaly Kuzmichev Acked-by: Dean Jenkins Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth

2013-11-15T19:18:45+00:00

Bluetooth: Fix to set proper bdaddr_type for RFCOMM connect

2013-11-13T13:36:53+00:00

L2CAP socket validates proper bdaddr_type for connect, so this patch fixes to set explictly bdaddr_type for RFCOMM connect. Signed-off-by: Seung-Woo Kim Signed-off-by: Marcel Holtmann

Bluetooth: Fix RFCOMM bind fail for L2CAP sock

2013-11-13T13:36:53+00:00

L2CAP socket bind checks its bdaddr type but RFCOMM kernel thread does not assign proper bdaddr type for L2CAP sock. This can cause that RFCOMM failure. Signed-off-by: Seung-Woo Kim Signed-off-by: Marcel Holtmann

Bluetooth: Use IS_ERR_OR_NULL for checking bt_debugfs

2013-10-18T07:45:19+00:00

Make sure to use IS_ERR_OR_NULL for checking the existing of the root debugfs dentry bt_debugfs. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: Access RFCOMM session addresses through L2CAP channel

2013-10-13T17:00:28+00:00

The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Bluetooth: fix error return code in rfcomm_add_listener()

2013-03-20T17:17:52+00:00

Fix to return a negative error code from the error handling case instead of 0, as returned elsewhere in this function. Signed-off-by: Wei Yongjun Signed-off-by: Gustavo Padovan

Bluetooth: Remove redundant RFCOMM BT_CLOSED settings

2013-03-08T13:40:25+00:00

rfcomm_session_close() sets the RFCOMM session state to BT_CLOSED. However, in multiple places immediately before the function is called, the RFCOMM session is set to BT_CLOSED. Therefore, remove these unnecessary state settings. Signed-off-by: Dean Jenkins Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan

Bluetooth: Remove redundant call to rfcomm_send_disc

2013-03-08T13:40:25+00:00

In rfcomm_session_del() remove the redundant call to rfcomm_send_disc() because it is not possible for the session to be in BT_CONNECTED state during deletion of the session. Signed-off-by: Dean Jenkins Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan

Bluetooth: Remove RFCOMM session refcnt

2013-03-08T13:40:24+00:00

Previous commits have improved the handling of the RFCOMM session timer and the RFCOMM session pointers such that freed RFCOMM session structures should no longer be erroneously accessed. The RFCOMM session refcnt now has no purpose and will be deleted by this commit. Note that the RFCOMM session is now deleted as soon as the RFCOMM control channel link is no longer required. This makes the lifetime of the RFCOMM session deterministic and absolute. Previously with the refcnt, there was uncertainty about when the session structure would be deleted because the relative refcnt prevented the session structure from being deleted at will. It was noted that the refcnt could malfunction under very heavy real-time processor loading in embedded SMP environments. This could cause premature RFCOMM session deletion or double session deletion that could result in kernel crashes. Removal of the refcnt prevents this issue. There are 4 connection / disconnection RFCOMM session scenarios: host initiated control link ---> host disconnected control link host initiated ctrl link ---> remote device disconnected ctrl link remote device initiated ctrl link ---> host disconnected ctrl link remote device initiated ctrl link ---> remote device disc'ed ctrl link The control channel connection procedures are independent of the disconnection procedures. Strangely, the RFCOMM session refcnt was applying special treatment so erroneously combining connection and disconnection events. This commit fixes this issue by removing some session code that used the "initiator" member of the session structure that was intended for use with the data channels. Signed-off-by: Dean Jenkins Acked-by: Marcel Holtmann Signed-off-by: Gustavo Padovan