linux-kernel - Re: [PATCH -next] mtd/ftl: Fix memleak in ftl_add

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]

Date:   Fri, 19 Aug 2022 10:37:22 +0800
From:   cuigaosheng <cuigaosheng1@...wei.com>
To:     Richard Weinberger <richard@....at>, <cuigaosheng1@...wei.com>
CC:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        <gongruiqi1@...wei.com>, <wangweiyang2@...wei.com>
Subject: Re: [PATCH -next] mtd/ftl: Fix memleak in ftl_add_mtd()

> There seems to be a problem with your caps lock key. ;-)

I wil adjust my caps lock key, Thanks for reminding.

> Is this leak observable via kmemleak or such?
> I always thought ->remove_dev() unconditionally do a cleanup later.

When I'm working on other issues with mtd,I needed to analyze the mtd driver
initialization process,during reading the code, refer to other driver
implementation，I found this problem, not kmemleak. Thanks.

在 2022/8/18 14:59, Richard Weinberger 写道:
> ----- Ursprüngliche Mail -----
>> Von: "cuigaosheng" <cuigaosheng1@...wei.com>
>>
>> PING
> There seems to be a problem with your caps lock key. ;-)
>   
>> 在 2022/7/15 15:11, Gaosheng Cui 写道:
>>> When add_mtd_blktrans_dev failed, partition's memory will be freed
>>> by kfree, but there are some structure members that are allocated
>>> for memory independently, such as partition->VirtualBlockMap,
>>> partition->EUNInfo, partition->ZferInfo, and partition->bam_cache,
>>> so kfree(partition) may cause memory leaks, using ftl_freepart(partition)
>>> will fix it.
> Is this leak observable via kmemleak or such?
> I always thought ->remove_dev() unconditionally do a cleanup later.
>
>>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>>> Signed-off-by: Gaosheng Cui <cuigaosheng1@...wei.com>
>>> ---
>>>    drivers/mtd/ftl.c | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mtd/ftl.c b/drivers/mtd/ftl.c
>>> index f655d2905270..200271bdc7aa 100644
>>> --- a/drivers/mtd/ftl.c
>>> +++ b/drivers/mtd/ftl.c
>>> @@ -1031,6 +1031,7 @@ static void ftl_add_mtd(struct mtd_blktrans_ops *tr,
>>> struct mtd_info *mtd)
>>>    		partition->mbd.devnum = -1;
>>>    		if (!add_mtd_blktrans_dev(&partition->mbd))
>>>    			return;
>>> +		ftl_freepart(partition);
>>>    	}
>>>    
>>>    	kfree(partition);
> .