diff mbox series

[v2,1/1] mm: fix vma->anon_name memory leak for anonymous shmem VMAs

Message ID 20230105000241.1450843-1-surenb@google.com
State New
Headers
Series [v2,1/1] mm: fix vma->anon_name memory leak for anonymous shmem VMAs |

Commit Message

Suren Baghdasaryan Jan. 5, 2023, 12:02 a.m. UTC 
  free_anon_vma_name() is missing a check for anonymous shmem VMA which
leads to a memory leak due to refcount not being dropped.  Fix this by
calling anon_vma_name_put() unconditionally. It will free vma->anon_name
whenever it's non-NULL.

Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Suggested-by: David Hildenbrand <david@redhat.com>
Reported-by: syzbot+91edf9178386a07d06a7@syzkaller.appspotmail.com
Cc: David Hildenbrand <david@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>
---
applies over mm-hotfixes-unstable branch of
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tree after reverting
the original version of this patch.

 include/linux/mm_inline.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Comments

Andrew Morton Jan. 5, 2023, 1:38 a.m. UTC | #1 
On Wed,  4 Jan 2023 16:02:40 -0800 Suren Baghdasaryan <surenb@google.com> wrote:

> free_anon_vma_name() is missing a check for anonymous shmem VMA which
> leads to a memory leak due to refcount not being dropped.  Fix this by
> calling anon_vma_name_put() unconditionally. It will free vma->anon_name
> whenever it's non-NULL.
> 
> Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")

A cc:stable is appropriate here, yes?
Suren Baghdasaryan Jan. 5, 2023, 2:39 a.m. UTC | #2 
On Wed, Jan 4, 2023 at 5:38 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed,  4 Jan 2023 16:02:40 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>
> > free_anon_vma_name() is missing a check for anonymous shmem VMA which
> > leads to a memory leak due to refcount not being dropped.  Fix this by
> > calling anon_vma_name_put() unconditionally. It will free vma->anon_name
> > whenever it's non-NULL.
> >
> > Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
>
> A cc:stable is appropriate here, yes?

Hmm. The patch we are fixing here was merged in 6.2-rc1. Should I CC
stable to fix the previous -rc branch?
David Hildenbrand Jan. 5, 2023, 9:03 a.m. UTC | #3 
On 05.01.23 03:39, Suren Baghdasaryan wrote:
> On Wed, Jan 4, 2023 at 5:38 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> On Wed,  4 Jan 2023 16:02:40 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>>
>>> free_anon_vma_name() is missing a check for anonymous shmem VMA which
>>> leads to a memory leak due to refcount not being dropped.  Fix this by
>>> calling anon_vma_name_put() unconditionally. It will free vma->anon_name
>>> whenever it's non-NULL.
>>>
>>> Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
>>
>> A cc:stable is appropriate here, yes?
> 
> Hmm. The patch we are fixing here was merged in 6.2-rc1. Should I CC
> stable to fix the previous -rc branch?
> 

No need for stable if it's not in a release kernel yet.
David Hildenbrand Jan. 5, 2023, 9:04 a.m. UTC | #4 
On 05.01.23 01:02, Suren Baghdasaryan wrote:
> free_anon_vma_name() is missing a check for anonymous shmem VMA which
> leads to a memory leak due to refcount not being dropped.  Fix this by
> calling anon_vma_name_put() unconditionally. It will free vma->anon_name
> whenever it's non-NULL.
> 
> Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Reported-by: syzbot+91edf9178386a07d06a7@syzkaller.appspotmail.com
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Pasha Tatashin <pasha.tatashin@soleen.com>


Reviewed-by: David Hildenbrand <david@redhat.com>
Holger Hoffstätte Jan. 5, 2023, 12:07 p.m. UTC | #5 
On 2023-01-05 10:03, David Hildenbrand wrote:
> On 05.01.23 03:39, Suren Baghdasaryan wrote:
>> On Wed, Jan 4, 2023 at 5:38 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>>
>>> On Wed,  4 Jan 2023 16:02:40 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>>>
>>>> free_anon_vma_name() is missing a check for anonymous shmem VMA which
>>>> leads to a memory leak due to refcount not being dropped.  Fix this by
>>>> calling anon_vma_name_put() unconditionally. It will free vma->anon_name
>>>> whenever it's non-NULL.
>>>>
>>>> Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
>>>
>>> A cc:stable is appropriate here, yes?
>>
>> Hmm. The patch we are fixing here was merged in 6.2-rc1. Should I CC
>> stable to fix the previous -rc branch?
>>
> 
> No need for stable if it's not in a release kernel yet.

Commit d09e8ca6cb93 is in 6.1. The fix applies cleanly.

cheers
Holger
David Hildenbrand Jan. 5, 2023, 12:18 p.m. UTC | #6 
On 05.01.23 13:07, Holger Hoffstätte wrote:
> On 2023-01-05 10:03, David Hildenbrand wrote:
>> On 05.01.23 03:39, Suren Baghdasaryan wrote:
>>> On Wed, Jan 4, 2023 at 5:38 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>>>
>>>> On Wed,  4 Jan 2023 16:02:40 -0800 Suren Baghdasaryan <surenb@google.com> wrote:
>>>>
>>>>> free_anon_vma_name() is missing a check for anonymous shmem VMA which
>>>>> leads to a memory leak due to refcount not being dropped.  Fix this by
>>>>> calling anon_vma_name_put() unconditionally. It will free vma->anon_name
>>>>> whenever it's non-NULL.
>>>>>
>>>>> Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming")
>>>>
>>>> A cc:stable is appropriate here, yes?
>>>
>>> Hmm. The patch we are fixing here was merged in 6.2-rc1. Should I CC
>>> stable to fix the previous -rc branch?
>>>
>>
>> No need for stable if it's not in a release kernel yet.
> 
> Commit d09e8ca6cb93 is in 6.1. The fix applies cleanly.

$ git tag --contains d09e8ca6cb93 | grep "^v"
v6.2-rc1
v6.2-rc2

Doesn't look like 6.1 to me.
diff mbox series

Patch

diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
index e8ed225d8f7c..ff3f3f23f649 100644
--- a/include/linux/mm_inline.h
+++ b/include/linux/mm_inline.h
@@ -413,8 +413,7 @@  static inline void free_anon_vma_name(struct vm_area_struct *vma)
 	 * Not using anon_vma_name because it generates a warning if mmap_lock
 	 * is not held, which might be the case here.
 	 */
-	if (!vma->vm_file)
-		anon_vma_name_put(vma->anon_name);
+	anon_vma_name_put(vma->anon_name);
 }
 
 static inline bool anon_vma_name_eq(struct anon_vma_name *anon_name1,