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
| ||
|
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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists