[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <41a5b57f-2bea-04a6-3510-6d76bd5098d5@redhat.com>
Date: Thu, 16 Jul 2020 06:48:39 -0700
From: Tom Rix <trix@...hat.com>
To: Jan Kara <jack@...e.cz>
Cc: Matthew Wilcox <willy@...radead.org>, william.kucharski@...cle.com,
jeffm@...e.com, joseph.qi@...ux.alibaba.com,
liao.pingfang@....com.cn, reiserfs-devel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] reiserfs : fix improper free in reiserfs_get_block
On 7/15/20 1:04 AM, Jan Kara wrote:
> On Tue 14-07-20 06:12:47, Tom Rix wrote:
>> On 7/14/20 6:10 AM, Matthew Wilcox wrote:
>>> On Tue, Jul 14, 2020 at 06:05:09AM -0700, trix@...hat.com wrote:
>>>> From: Tom Rix <trix@...hat.com>
>>>>
>>>> clang static analysis flags this error
>>>>
>>>> inode.c:1083:5: warning: Argument to kfree() is the address of the
>>>> local variable 'unf_single', which is not memory allocated by
>>>> malloc() [unix.Malloc]
>>>> kfree(un);
>>>> ^~~~~~~~~
>>>> Assignment of 'un'
>>>>
>>>> /*
>>>> * We use this in case we need to allocate
>>>> * only one block which is a fastpath
>>>> */
>>>> unp_t unf_single = 0;
>>>>
>>>> ...
>>>>
>>>> if (blocks_needed == 1) {
>>>> un = &unf_single;
>>>> } else {
>>>> un = kcalloc(min(blocks_needed, max_to_insert),
>>>> UNFM_P_SIZE, GFP_NOFS);
>>>> if (!un) {
>>>> un = &unf_single;
>>>> blocks_needed = 1;
>>>> max_to_insert = 0;
>>>> }
>>>> }
>>>>
>>>> The logic to free 'un'
>>>>
>>>> if (blocks_needed != 1)
>>>> kfree(un);
>>>>
>>>> Because the kcalloc failure falls back to using unf_single,
>>>> the if-check for the free is wrong.
>>> I think you mean "Because clang's static analysis is limited, it
>>> warns incorrectly about this". There's no path to get to the
>>> kfree with blocks_needed != 1 and un being equal to &unf_single.
>> Ok.
> I agree with Matthew the patch will make the code more obviously correct so
> it's a sensible cleanup. But the changelog needs to redone to reflect this
> is just a cleanup before the patch can be merged.
>
> Honza
I am going to look into the problem with the analyzer because that is where the fix should go.
If the problem isn't resolvable, i will loop back to this clean up.
Tom
Powered by blists - more mailing lists