linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dean Jenkins <Dean_Jenkins@mentor.com>
To: Dean Jenkins <Dean_Jenkins@mentor.com>,
	Marcel Holtmann <marcel@holtmann.org>,
	Gustavo Padovan <gustavo@padovan.org>,
	Johan Hedberg <johan.hedberg@gmail.com>
Cc: <linux-bluetooth@vger.kernel.org>
Subject: [PATCH V2 6/7] Revert "Bluetooth: hci_ldisc: Fix null pointer derefence in case of early data"
Date: Fri, 23 Sep 2016 18:56:31 +0100	[thread overview]
Message-ID: <1474653392-28770-7-git-send-email-Dean_Jenkins@mentor.com> (raw)
In-Reply-To: <1474653392-28770-1-git-send-email-Dean_Jenkins@mentor.com>

This reverts commit 84cb3df02aea4b00405521e67c4c67c2d525c364.

This commit solved the specific race condition mentioned in the commit:

"HCI_UART_PROTO_SET flag is set before hci_uart_set_proto call. If we
receive data from tty layer during this procedure, proto pointer may
not be assigned yet, leading to null pointer dereference in rx
method hci_uart_tty_receive.

This patch fixes this issue by introducing HCI_UART_PROTO_READY flag
in order to avoid any proto operation before proto opening and
assignment."

The design of the commit seems to be attempting to implement a
lockless solution by relying on atomic variables.

However, HCI_UART_PROTO_READY introduces a race condition here:

static int hci_uart_set_proto(struct hci_uart *hu,
...
        hu->proto = p;
+       set_bit(HCI_UART_PROTO_READY, &hu->flags);

        err = hci_uart_register_dev(hu);
        if (err) {
+               clear_bit(HCI_UART_PROTO_READY, &hu->flags);
                p->close(hu);
                return err;
        }

The issue here is that hci_uart_register_dev() allocates the
memory for hu->hdev and HCI_UART_PROTO_READY is set before
hdev is allocated. This means there is a risk that an unallocated hdev
is accessed because HCI_UART_PROTO_READY is set too early.

For example, hci_uart_tty_wakeup() used the HCI_UART_PROTO_READY flag
which means a transmission work item could potentially be scheduled
in hci_uart_tx_wakeup() when hdev has not been allocated.

Instead use a solution using locking supplied in commits:
"Bluetooth: Use single return in hci_uart_tty_ioctl() call"
"Bluetooth: Add mutex to hci_uart_tty_ioctl()"
"Bluetooth: Fix HCI UART HCI_UART_PROTO_SET locking"

Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com>
---
 drivers/bluetooth/hci_ldisc.c | 11 ++++-------
 drivers/bluetooth/hci_uart.h  |  1 -
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 1fc9817..499fb09 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -229,7 +229,7 @@ static int hci_uart_flush(struct hci_dev *hdev)
 	tty_ldisc_flush(tty);
 	tty_driver_flush_buffer(tty);
 
-	if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
+	if (test_bit(HCI_UART_PROTO_SET, &hu->flags))
 		hu->proto->flush(hu);
 
 	return 0;
@@ -494,7 +494,7 @@ static void hci_uart_tty_close(struct tty_struct *tty)
 
 	cancel_work_sync(&hu->write_work);
 
-	if (test_and_clear_bit(HCI_UART_PROTO_READY, &hu->flags)) {
+	if (test_and_clear_bit(HCI_UART_PROTO_SET, &hu->flags)) {
 		if (hdev) {
 			if (test_bit(HCI_UART_REGISTERED, &hu->flags))
 				hci_unregister_dev(hdev);
@@ -502,7 +502,6 @@ static void hci_uart_tty_close(struct tty_struct *tty)
 		}
 		hu->proto->close(hu);
 	}
-	clear_bit(HCI_UART_PROTO_SET, &hu->flags);
 
 	kfree(hu);
 }
@@ -529,7 +528,7 @@ static void hci_uart_tty_wakeup(struct tty_struct *tty)
 	if (tty != hu->tty)
 		return;
 
-	if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
+	if (test_bit(HCI_UART_PROTO_SET, &hu->flags))
 		hci_uart_tx_wakeup(hu);
 }
 
@@ -553,7 +552,7 @@ static void hci_uart_tty_receive(struct tty_struct *tty, const u8 *data,
 	if (!hu || tty != hu->tty)
 		return;
 
-	if (!test_bit(HCI_UART_PROTO_READY, &hu->flags))
+	if (!test_bit(HCI_UART_PROTO_SET, &hu->flags))
 		return;
 
 	/* It does not need a lock here as it is already protected by a mutex in
@@ -641,11 +640,9 @@ static int hci_uart_set_proto(struct hci_uart *hu, int id)
 		return err;
 
 	hu->proto = p;
-	set_bit(HCI_UART_PROTO_READY, &hu->flags);
 
 	err = hci_uart_register_dev(hu);
 	if (err) {
-		clear_bit(HCI_UART_PROTO_READY, &hu->flags);
 		p->close(hu);
 		return err;
 	}
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 0701395..f0707f4 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -97,7 +97,6 @@ struct hci_uart {
 /* HCI_UART proto flag bits */
 #define HCI_UART_PROTO_SET	0
 #define HCI_UART_REGISTERED	1
-#define HCI_UART_PROTO_READY	2
 
 /* TX states  */
 #define HCI_UART_SENDING	1
-- 
2.7.4

  parent reply	other threads:[~2016-09-23 17:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23 17:56 [PATCH V2 0/7] Bluetooth HCI LDISC and BCSP fixes Dean Jenkins
2016-09-23 17:56 ` [PATCH V2 1/7] Bluetooth: Tidy-up coding style in hci_bcsp.c Dean Jenkins
2016-09-23 17:56 ` [PATCH V2 2/7] Bluetooth: BCSP fails to ACK re-transmitted frames from the peer Dean Jenkins
2016-09-23 17:56 ` [PATCH V2 3/7] Bluetooth: Use single return in hci_uart_tty_ioctl() call Dean Jenkins
2016-09-23 17:56 ` [PATCH V2 4/7] Bluetooth: Add mutex to hci_uart_tty_ioctl() Dean Jenkins
2016-09-24  4:41   ` Marcel Holtmann
2016-09-23 17:56 ` [PATCH V2 5/7] Bluetooth: Fix HCI UART HCI_UART_PROTO_SET locking Dean Jenkins
2016-09-24  4:41   ` Marcel Holtmann
2016-09-23 17:56 ` Dean Jenkins [this message]
2016-09-23 17:56 ` [PATCH V2 7/7] Bluetooth: Prevent scheduling of work after hci_uart_tty_close() Dean Jenkins
2016-09-24  4:41 ` [PATCH V2 0/7] Bluetooth HCI LDISC and BCSP fixes Marcel Holtmann

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=1474653392-28770-7-git-send-email-Dean_Jenkins@mentor.com \
    --to=dean_jenkins@mentor.com \
    --cc=gustavo@padovan.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.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).