linux-kernel - Re: [RFC][-rc9 PATCH] Bluetooth: fix oops in rfcomm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a8e1da0807140006u6d091e15m40c1fb05fcdec893@mail.gmail.com>
Date:	Mon, 14 Jul 2008 15:06:33 +0800
From:	"Dave Young" <hidave.darkstar@...il.com>
To:	"Vegard Nossum" <vegard.nossum@...il.com>
Cc:	"Soeren Sonnenburg" <kernel@....de>,
	"Marcel Holtmann" <marcel@...tmann.org>,
	"David Woodhouse" <dwmw2@...radead.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC][-rc9 PATCH] Bluetooth: fix oops in rfcomm

On Mon, Jul 14, 2008 at 2:23 PM, Vegard Nossum <vegard.nossum@...il.com> wrote:
> On Mon, Jul 14, 2008 at 4:41 AM, Dave Young <hidave.darkstar@...il.com> wrote:
>>> This patch attempts to correct this by only removing the device from the
>>> internal rfcomm list of devices at the final unregister, so that the id
>>> won't get reused until the device has been completely destructed.
>>
>> It looks good, I agree with your change.
>
> Thanks for looking!
>
>>        if (IS_ERR(dev->tty_dev)) {
>>                err = PTR_ERR(dev->tty_dev);
>>                list_del(&dev->list);
>>                kfree(dev);
>>                return err;
>>        }
>>
>> The list_del need to be protected as well.
>
> After looking at the code once again I wonder if we should not extend
> the protection even a bit further. Just below, we have this:
>
>        if (device_create_file(dev->tty_dev, &dev_attr_address) < 0)
>
> ..which means that we could theoretically get here, be preempted by
> another process which 1. releases the device id, and 2. recreates the
> same device id. When we resume execution of the first task,
> device_create_file() would be called for a file that already exists.
>
> Should the rfcomm_dev_lock be extended to include protecting these
> things as well? It seems somehow wrong, but I am not sure how it
> should be done correctly either.

I think they need some locking indeed, but I guess rfcomm_dev_lock is
not the one for it.

Another problem, please see the following code:

        /* Refcount should only hit zero when called from rfcomm_dev_del()
           which will have taken us off the list. Everything else are
           refcounting bugs. */
        BUG_ON(!list_empty(&dev->list));

Maybe replace it with BUG_ON(!test_bit(RFCOMM_TTY_RELEASED, &dev->flags))?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/