From 6fdf658c9a0e51e6663f2769f6d310c2843a862b Mon Sep 17 00:00:00 2001 From: Luiz Augusto von Dentz Date: Mon, 13 Jun 2011 15:37:35 +0300 Subject: [PATCH 1/5] Bluetooth: Fix L2CAP security check With older userspace versions (using hciops) it might not have the key type to check if the key has sufficient security for any security level so it is necessary to check the return of hci_conn_auth to make sure the connection is authenticated Signed-off-by: Luiz Augusto von Dentz Acked-by: Johan Hedberg Signed-off-by: Gustavo F. Padovan --- net/bluetooth/hci_conn.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 3163330cd4f1..b9aa9862d14b 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -611,8 +611,8 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type) if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend)) return 0; - hci_conn_auth(conn, sec_level, auth_type); - return 0; + if (!hci_conn_auth(conn, sec_level, auth_type)) + return 0; encrypt: if (conn->link_mode & HCI_LM_ENCRYPT) From df3c3931ec58cca3409c71b18ad6da0cd71fe163 Mon Sep 17 00:00:00 2001 From: Johan Hedberg Date: Tue, 14 Jun 2011 12:48:19 +0300 Subject: [PATCH 2/5] Bluetooth: Fix accepting connect requests for defer_setup When authentication completes we shouldn't blindly accept any pending L2CAP connect requests. If the socket has the defer_setup feature enabled it should still wait for user space acceptance of the connect request. The issue only happens for non-SSP connections since with SSP the L2CAP Connect request may not be sent for non-SDP PSMs before authentication has completed successfully. Signed-off-by: Johan Hedberg Signed-off-by: Gustavo F. Padovan --- net/bluetooth/l2cap_core.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index e64a1c2df238..56fdd9162da9 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -4002,21 +4002,30 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt) } } else if (sk->sk_state == BT_CONNECT2) { struct l2cap_conn_rsp rsp; - __u16 result; + __u16 res, stat; if (!status) { - sk->sk_state = BT_CONFIG; - result = L2CAP_CR_SUCCESS; + if (bt_sk(sk)->defer_setup) { + struct sock *parent = bt_sk(sk)->parent; + res = L2CAP_CR_PEND; + stat = L2CAP_CS_AUTHOR_PEND; + parent->sk_data_ready(parent, 0); + } else { + sk->sk_state = BT_CONFIG; + res = L2CAP_CR_SUCCESS; + stat = L2CAP_CS_NO_INFO; + } } else { sk->sk_state = BT_DISCONN; l2cap_sock_set_timer(sk, HZ / 10); - result = L2CAP_CR_SEC_BLOCK; + res = L2CAP_CR_SEC_BLOCK; + stat = L2CAP_CS_NO_INFO; } rsp.scid = cpu_to_le16(chan->dcid); rsp.dcid = cpu_to_le16(chan->scid); - rsp.result = cpu_to_le16(result); - rsp.status = cpu_to_le16(L2CAP_CS_NO_INFO); + rsp.result = cpu_to_le16(res); + rsp.status = cpu_to_le16(stat); l2cap_send_cmd(conn, chan->ident, L2CAP_CONN_RSP, sizeof(rsp), &rsp); } From 330605423ca6eafafb8dcc27502bce1c585d1b06 Mon Sep 17 00:00:00 2001 From: Ilia Kolomisnky Date: Wed, 15 Jun 2011 06:52:26 +0300 Subject: [PATCH 3/5] Bluetooth: Fix L2CAP connection establishment In hci_conn_security ( which is used during L2CAP connection establishment ) test for HCI_CONN_ENCRYPT_PEND state also sets this state, which is bogus and leads to connection time-out on L2CAP sockets in certain situations (especially when using non-ssp devices ) Signed-off-by: Ilia Kolomisnky Signed-off-by: Gustavo F. Padovan --- net/bluetooth/hci_conn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index b9aa9862d14b..d3a05b9ade7a 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -608,7 +608,7 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type) goto encrypt; auth: - if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend)) + if (test_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend)) return 0; if (!hci_conn_auth(conn, sec_level, auth_type)) From fa7ccfb17033bfb5bca86f6b909cab0b807efbc0 Mon Sep 17 00:00:00 2001 From: Larry Finger Date: Sat, 18 Jun 2011 22:49:53 -0500 Subject: [PATCH 4/5] rtlwifi: rtl8192se: Handle duplicate PCI ID 0x10ec:0x8192 conflict with r8192e_pci There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and RTL8192SE. The method of distinguishing them is by the revision ID at offset 0x8 of the PCI configuration space. If the value is 0x10, then the device uses rtl8192se for a driver. Signed-off-by: Larry Finger Signed-off-by: John W. Linville --- drivers/net/wireless/rtlwifi/pci.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c index 9f8ccae93317..254b64ba4bf6 100644 --- a/drivers/net/wireless/rtlwifi/pci.c +++ b/drivers/net/wireless/rtlwifi/pci.c @@ -1624,6 +1624,16 @@ static bool _rtl_pci_find_adapter(struct pci_dev *pdev, pci_read_config_byte(pdev, 0x8, &revisionid); pci_read_config_word(pdev, 0x3C, &irqline); + /* PCI ID 0x10ec:0x8192 occurs for both RTL8192E, which uses + * r8192e_pci, and RTL8192SE, which uses this driver. If the + * revision ID is RTL_PCI_REVISION_ID_8192PCIE (0x01), then + * the correct driver is r8192e_pci, thus this routine should + * return false. + */ + if (deviceid == RTL_PCI_8192SE_DID && + revisionid == RTL_PCI_REVISION_ID_8192PCIE) + return false; + if (deviceid == RTL_PCI_8192_DID || deviceid == RTL_PCI_0044_DID || deviceid == RTL_PCI_0047_DID || @@ -1856,7 +1866,8 @@ int __devinit rtl_pci_probe(struct pci_dev *pdev, pci_write_config_byte(pdev, 0x04, 0x07); /* find adapter */ - _rtl_pci_find_adapter(pdev, hw); + if (!_rtl_pci_find_adapter(pdev, hw)) + goto fail3; /* Init IO handler */ _rtl_pci_io_handler_init(&pdev->dev, hw); From 9935d12651c9e54ad266e17cd542ec717ccd0fc8 Mon Sep 17 00:00:00 2001 From: Larry Finger Date: Tue, 21 Jun 2011 10:48:31 -0500 Subject: [PATCH 5/5] rtl8192cu: Fix missing firmware load In commit 3ac5e26a1e935469a8bdae1d624bc3b59d1fcdc5 entitled "rtlwifi: rtl8192c-common: Change common firmware routines for addition of rtl8192se and rtl8192de", the firmware loading code was moved. Unfortunately, some necessary code was dropped for rtl8192cu. The dmesg output shows the following: rtl8192c: Loading firmware file rtlwifi/rtl8192cufw.bin rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready fail!! REG_MCUFWDL:0x00000006 . rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not ready to run! In addition, the interface will authenticate and associate, but cannot transfer data. This is reported as Kernel Bug #38012. Signed-off-by: Larry Finger Signed-off-by: John W. Linville --- drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c index bee7c1480f63..092e342c19df 100644 --- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c @@ -53,6 +53,8 @@ MODULE_FIRMWARE("rtlwifi/rtl8192cufw.bin"); static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw) { struct rtl_priv *rtlpriv = rtl_priv(hw); + const struct firmware *firmware; + int err; rtlpriv->dm.dm_initialgain_enable = 1; rtlpriv->dm.dm_flag = 0; @@ -64,6 +66,24 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw) ("Can't alloc buffer for fw.\n")); return 1; } + /* request fw */ + err = request_firmware(&firmware, rtlpriv->cfg->fw_name, + rtlpriv->io.dev); + if (err) { + RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, + ("Failed to request firmware!\n")); + return 1; + } + if (firmware->size > 0x4000) { + RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, + ("Firmware is too big!\n")); + release_firmware(firmware); + return 1; + } + memcpy(rtlpriv->rtlhal.pfirmware, firmware->data, firmware->size); + rtlpriv->rtlhal.fwsize = firmware->size; + release_firmware(firmware); + return 0; }