All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Dan Carpenter <dan.carpenter@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "Jérôme Glisse" <jglisse@redhat.com>,
	"Markus Elfring" <Markus.Elfring@web.de>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Wei Yongjun" <weiyongjun1@huawei.com>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH v3] mm/hmm/test: use after free in dmirror_allocate_chunk()
Date: Sat, 26 Sep 2020 22:17:20 +0000	[thread overview]
Message-ID: <20200926221720.GK9916@ziepe.ca> (raw)
In-Reply-To: <20200926121402.GA7467@kadam>

On Sat, Sep 26, 2020 at 03:14:02PM +0300, Dan Carpenter wrote:
> The error handling code does this:
> 
> err_free:
> 	kfree(devmem);
>         ^^^^^^^^^^^^^
> err_release:
> 	release_mem_region(devmem->pagemap.range.start, range_len(&devmem->pagemap.range));
>                            ^^^^^^^^
> The problem is that when we use "devmem->pagemap.range.start" the
> "devmem" pointer is either NULL or freed.
> 
> Neither the allocation nor the call to request_free_mem_region() has to
> be done under the lock so I moved those to the start of the function.
> 
> Fixes: 1f9c4bb986d9 ("mm/memremap_pages: convert to 'struct range'")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com>
> ---
> v2: The first version introduced a locking bug
> v3: Markus Elfring pointed out that the Fixes tag was wrong.  This bug
> was in the original commit and then fixed and then re-introduced.  I was
> quite bothered by how this bug lasted so long in the source code, but
> now we know.  As soon as it is introduced we fixed it.
> 
> One problem with the kernel QC process is that I think everyone marks
> the bug as "old/dealt with" so it was only because I was added a new
> check for resource leaks that it was found when it was re-introduced.
> 
>  lib/test_hmm.c | 44 ++++++++++++++++++++++----------------------
>  1 file changed, 22 insertions(+), 22 deletions(-)

Hi Andrew, 

I don't have have any hmm related patches this cycle, can you take
this into your tree?

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Thanks,
Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Dan Carpenter <dan.carpenter@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "Jérôme Glisse" <jglisse@redhat.com>,
	"Markus Elfring" <Markus.Elfring@web.de>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Wei Yongjun" <weiyongjun1@huawei.com>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [PATCH v3] mm/hmm/test: use after free in dmirror_allocate_chunk()
Date: Sat, 26 Sep 2020 19:17:20 -0300	[thread overview]
Message-ID: <20200926221720.GK9916@ziepe.ca> (raw)
In-Reply-To: <20200926121402.GA7467@kadam>

On Sat, Sep 26, 2020 at 03:14:02PM +0300, Dan Carpenter wrote:
> The error handling code does this:
> 
> err_free:
> 	kfree(devmem);
>         ^^^^^^^^^^^^^
> err_release:
> 	release_mem_region(devmem->pagemap.range.start, range_len(&devmem->pagemap.range));
>                            ^^^^^^^^
> The problem is that when we use "devmem->pagemap.range.start" the
> "devmem" pointer is either NULL or freed.
> 
> Neither the allocation nor the call to request_free_mem_region() has to
> be done under the lock so I moved those to the start of the function.
> 
> Fixes: 1f9c4bb986d9 ("mm/memremap_pages: convert to 'struct range'")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com>
> ---
> v2: The first version introduced a locking bug
> v3: Markus Elfring pointed out that the Fixes tag was wrong.  This bug
> was in the original commit and then fixed and then re-introduced.  I was
> quite bothered by how this bug lasted so long in the source code, but
> now we know.  As soon as it is introduced we fixed it.
> 
> One problem with the kernel QC process is that I think everyone marks
> the bug as "old/dealt with" so it was only because I was added a new
> check for resource leaks that it was found when it was re-introduced.
> 
>  lib/test_hmm.c | 44 ++++++++++++++++++++++----------------------
>  1 file changed, 22 insertions(+), 22 deletions(-)

Hi Andrew, 

I don't have have any hmm related patches this cycle, can you take
this into your tree?

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Thanks,
Jason


  parent reply	other threads:[~2020-09-26 22:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 19:30 [PATCH v2] mm/hmm/test: use after free in dmirror_allocate_chunk() Markus Elfring
2020-09-26 12:14 ` [PATCH v3] " Dan Carpenter
2020-09-26 12:14   ` Dan Carpenter
2020-09-26 13:10   ` Markus Elfring
2020-09-26 22:17   ` Jason Gunthorpe [this message]
2020-09-26 22:17     ` Jason Gunthorpe
2020-09-29  0:52     ` Andrew Morton
2020-09-29  0:52       ` Andrew Morton
2020-09-29  1:25       ` Dan Williams
2020-09-29  1:25         ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200926221720.GK9916@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=Markus.Elfring@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=jglisse@redhat.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rcampbell@nvidia.com \
    --cc=weiyongjun1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.