xorl %eax, %eax

CVE-2010-4242: Linux kernel Bluetooth HCI UART Invalid Pointer Access

with 2 comments

Reported by Eugene Teo, this issue is about Bluetooth HCI UART driver and specifically, a missing check during TTY opening code. Its code is available at drivers/bluetooth/hci_ldisc.c and below is the buggy function.

/* ------ LDISC part ------ */
/* hci_uart_tty_open
 * 
 *     Called when line discipline changed to HCI_UART.
 *
 * Arguments:
 *     tty    pointer to tty info structure
 * Return Value:    
 *     0 if success, otherwise error code
 */
static int hci_uart_tty_open(struct tty_struct *tty)
{
        struct hci_uart *hu = (void *) tty->disc_data;

        BT_DBG("tty %p", tty);

        if (hu)
                return -EEXIST;

        if (!(hu = kzalloc(sizeof(struct hci_uart), GFP_KERNEL))) {
                BT_ERR("Can't allocate control structure");
                return -ENFILE;
        }
 
         tty->disc_data = hu;
        hu->tty = tty;
        tty->receive_room = 65536;

        spin_lock_init(&hu->rx_lock);

        /* Flush any pending characters in the driver and line discipline. */

        /* FIXME: why is this needed. Note don't use ldisc_ref here as the
           open path is before the ldisc is referencable */

        if (tty->ldisc->ops->flush_buffer)
                tty->ldisc->ops->flush_buffer(tty);
        tty_driver_flush_buffer(tty);

        return 0;
}

And the patch was:

        BT_DBG("tty %p", tty);
 
+       /* FIXME: This btw is bogus, nothing requires the old ldisc to clear
+          the pointer */
        if (hu)
                return -EEXIST;
 
+       /* Error if the tty has no write op instead of leaving an exploitable
+          hole */
+       if (tty->ops->write == NULL)
+               return -EOPNOTSUPP;
+
        if (!(hu = kzalloc(sizeof(struct hci_uart), GFP_KERNEL))) {
                BT_ERR("Can't allocate control structure");

Alan Cox stated that “this is only exploitable on very unusual hardware” where there is no write operation initialized allowing the user to perform a very straightforward privilege escalation exploit.

Written by xorl

December 1, 2010 at 08:32

Posted in linux, vulnerabilities

2 Responses

Subscribe to comments with RSS.

  1. How exactly would this be a “very straightforward privilege escalation exploit”? Unless you have some secret way of getting around mmap_min_addr, this is just a DoS.

    Dan Rosenberg

    December 1, 2010 at 08:53

  2. I guess your question was rhetorical since you gave the answer.
    Many of the people you mock on certain IRC channels also have some “secrets”.

    xorl

    December 1, 2010 at 09:13


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: