linux-kernel - Re: Possible memory leak in request

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]

Message-ID: <d82e647a0907071718l79e9eab8s67ae3a972003cf8d@mail.gmail.com>
Date:	Wed, 8 Jul 2009 08:18:25 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Possible memory leak in request_firmware()

2009/7/7 Catalin Marinas <catalin.marinas@....com>:
> Hi,
>
> I get a couple kmemleak reports like below which I think happen on the
> failure path (-ENOENT) of a request_firmware() call:
>
> unreferenced object 0xc355fdb0 (size 256):
>  comm "NetworkManager", pid 2606, jiffies 4294902882
>  backtrace:
>    [<c01e0c3a>] create_object+0xfa/0x250
>    [<c01e1e7d>] kmemleak_alloc+0x5d/0x70
>    [<c01dac1b>] kmem_cache_alloc+0x14b/0x190
>    [<c03a0c4c>] _request_firmware+0x11c/0x530
>    [<c03a1102>] request_firmware+0x12/0x20
>    [<f95f6591>] iwl_mac_start+0xa1/0x850 [iwlagn]
>    [<f8fb08c1>] ieee80211_open+0x2e1/0x860 [mac80211]
>    [<c048459a>] dev_open+0xba/0x100
>    [<c0483ab9>] dev_change_flags+0x139/0x1d0
>    [<c048d392>] do_setlink+0x282/0x410
>    [<c048ea81>] rtnl_setlink+0xf1/0x130
>    [<c048e285>] rtnetlink_rcv_msg+0x165/0x200
>    [<c049fac6>] netlink_rcv_skb+0x76/0xa0
>    [<c048e10e>] rtnetlink_rcv+0x1e/0x30
>    [<c049f7fb>] netlink_unicast+0x23b/0x250
>    [<c04a02db>] netlink_sendmsg+0x1db/0x2d0
>
> The f_dev in _request_firmware() is allocated via the fw_setup_device()
> and fw_register_device() calls and its class set to firmware_class (the
> class release function is fw_dev_release).
>
> Commit 6acf70f078ca replaced the kfree(dev) in fw_dev_release() with a
> put_device() call but my understanding is that the release function is
> called via put_device -> kobject_put -> kref_put -> koject_release etc.
> and it should call kfree since it's the last to see this device
> structure alive.
>
> Because of that, the _request_firmware() function on its -ENOENT error
> path only calls device_unregister(f_dev) which would eventually call
> fw_dev_release() but there is no kfree (the subsequent put_device call
> would just make the kref negative).
>
> The patch below may fix the problem but it's only later tonight that I
> can test it and confirm:
>
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index ddeb819..12e6e64 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -357,7 +357,7 @@ static void fw_dev_release(struct device *dev)
>        kfree(fw_priv->pages);
>        kfree(fw_priv->fw_id);
>        kfree(fw_priv);
> -       put_device(dev);
> +       kfree(dev);

Ackd-by: Ming Lei <tom.leiming@...il.com>

Thanks.

>
>        module_put(THIS_MODULE);
>  }
> @@ -407,14 +407,13 @@ static int fw_register_device(struct device **dev_p, const char *fw_name,
>        retval = device_register(f_dev);
>        if (retval) {
>                dev_err(device, "%s: device_register failed\n", __func__);
> +               kfree(fw_priv->fw_id);
>                put_device(f_dev);
> -               goto error_kfree_fw_id;
> +               return retval;
>        }
>        *dev_p = f_dev;
>        return 0;
>
> -error_kfree_fw_id:
> -       kfree(fw_priv->fw_id);
>  error_kfree:
>        kfree(f_dev);
>        kfree(fw_priv);
>
>
> --
> Catalin
>
>



-- 
Lei Ming
--
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/