linux-kernel - Re: [PATCH] ocfs2: possible memory leak in mlog_sys

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, 18 Oct 2022 22:28:32 +0800
From:   Yang Yingliang <yangyingliang@...wei.com>
To:     Joseph Qi <joseph.qi@...ux.alibaba.com>,
        <linux-kernel@...r.kernel.org>, <ocfs2-devel@....oracle.com>
CC:     <mark@...heh.com>, <jlbec@...lplan.org>,
        <gregkh@...uxfoundation.org>, <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()


On 2022/10/18 21:39, Joseph Qi wrote:
>
> On 10/18/22 6:33 PM, Yang Yingliang wrote:
>> Hi,
>>
>> On 2022/10/18 17:02, Joseph Qi wrote:
>>> Hi,
>>>
>>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>>>> Inject fault while probing module, kset_register() may fail,
>>>> if it fails, but the refcount of kobject is not decreased to
>>>> 0, the name allocated in kobject_set_name() is leaked. Fix
>>>> this by calling kset_put(), so that name can be freed in
>>>> callback function kobject_cleanup().
>>>>
>>>> unreferenced object 0xffff888100da9348 (size 8):
>>>>     comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>>>     hex dump (first 8 bytes):
>>>>       6c 6f 67 6d 61 73 6b 00                          logmask.
>>>>     backtrace:
>>>>       [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>>>       [<000000007c491a9e>] kstrdup+0x3a/0x70
>>>>       [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>>>       [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>>>       [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>>>       [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>>>
>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>>>> Signed-off-by: Yang Yingliang <yangyingliang@...wei.com>
>>>> ---
>>>>    fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>>>    1 file changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>>>> index 563881ddbf00..7f9ba816d955 100644
>>>> --- a/fs/ocfs2/cluster/masklog.c
>>>> +++ b/fs/ocfs2/cluster/masklog.c
>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>>>    int mlog_sys_init(struct kset *o2cb_kset)
>>>>    {
>>>>        int i = 0;
>>>> +    int ret;
>>>>          while (mlog_attrs[i].attr.mode) {
>>>>            mlog_default_attrs[i] = &mlog_attrs[i].attr;
>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>>>          kobject_set_name(&mlog_kset.kobj, "logmask");
>>>>        mlog_kset.kobj.kset = o2cb_kset;
>>>> -    return kset_register(&mlog_kset);
>>>> +    ret = kset_register(&mlog_kset);
>>> If register fails, it will call unregister in o2cb_sys_init(), which
>>> will put kobject.
>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
>> refcounts.
>> Yes, you are right. I've mixed the two ksets up.
> In theory, kset_register() may return error because of a NULL kset, so
> here we may not call kset_put() directly, I'm not sure if a static
> checker will happy.
> Though this can't happen since it's already statically allocated...
kset_register() may fail if kobject_add_internal() return error (can't 
allocate memory), the name
"logmask" is dynamically alloctated while ocfs2 is compile as module and 
insert it (if ocfs2 is
built in kernel, the name is constant, it won't cause a leak), so the 
name can be leaked.

Thanks,
Yang
>
> Thanks,
> Joseph
>
> .