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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 28 Apr 2009 08:51:43 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Greg KH <gregkh@...e.de>
CC:	Kay Sievers <kay.sievers@...y.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org
Subject: Re: [RFC PATCH] use dev_set_name(,NULL) to prevent leaking

Greg KH wrote:
> On Tue, Apr 28, 2009 at 08:34:29AM -0700, Yinghai Lu wrote:
>> Yinghai Lu wrote:
>>> Kay Sievers wrote:
>>>> On Tue, Apr 28, 2009 at 09:42, Yinghai Lu <yinghai@...nel.org> wrote:
>>>>> those about 1/3 dev_set_name() etc.
>>>> put_device()?
>>>>
>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/base/core.c;h=4aa527b8a91381289eb175b33f46e3e418d10374;hb=HEAD#l848
>>>>
>>> ok, normal release path seems right, put_device will free the name.
>>>
>>> how about other fail path, that there is not put_device involved?
>>>
>>  
>> looks like need to follow this pattern
>>
>> static int
>> sa1111_init_one_child(struct sa1111 *sachip, struct resource *parent,
>>                       struct sa1111_dev_info *info)
>> {
>>         struct sa1111_dev *dev;
>>         int ret;
>>
>>         dev = kzalloc(sizeof(struct sa1111_dev), GFP_KERNEL);
>>         if (!dev) {
>>                 ret = -ENOMEM;
>>                 goto out;
>>         }
>>
>>         dev_set_name(&dev->dev, "%4.4lx", info->offset);
>>         dev->devid       = info->devid;
>>         dev->dev.parent  = sachip->dev;
>>         dev->dev.bus     = &sa1111_bus_type;
>>         dev->dev.release = sa1111_dev_release;
>>         dev->dev.coherent_dma_mask = sachip->dev->coherent_dma_mask;
>>         dev->res.start   = sachip->phys + info->offset;
>>         dev->res.end     = dev->res.start + 511;
>>         dev->res.name    = dev_name(&dev->dev);
>>         dev->res.flags   = IORESOURCE_MEM;
>>         dev->mapbase     = sachip->base + info->offset;
>>         dev->skpcr_mask  = info->skpcr_mask;
>>         memmove(dev->irq, info->irq, sizeof(dev->irq));
>>
>>         ret = request_resource(parent, &dev->res);
>>         if (ret) {
>>                 printk("SA1111: failed to allocate resource for %s\n",
>>                         dev->res.name);
>>                 dev_set_name(&dev->dev, NULL); ============> clear the name
>>                 kfree(dev);
>>                 goto out;
>>         }
>>         
>>
>>         ret = device_register(&dev->dev);
>>         if (ret) {
>>                 release_resource(&dev->res);
>>                 put_device(&dev->dev);   ==================> put the device...
>>                 kfree(dev);
>>                 goto out;
>>         }
> 
> You can just do a "put_device()" in both places, and it should be fine.
> 

before device_register==>device_initialize is called, kobj->ref is still 0.

will get warn from
                if (!kobj->state_initialized)
                        WARN(1, KERN_WARNING "kobject: '%s' (%p): is not "
                               "initialized, yet kobject_put() is being "
                               "called.\n", kobject_name(kobj), kobj);

also wonder
int kref_put(struct kref *kref, void (*release)(struct kref *kref))
{
        WARN_ON(release == NULL);
        WARN_ON(release == (void (*)(struct kref *))kfree);

        if (atomic_dec_and_test(&kref->refcount)) {
                release(kref);
                return 1;
        }
        return 0;
}

what will be return from atomic_dec_and_test

YH
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ