| Message ID | 20230105000241.1450843-1-surenb@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/1] mm: fix vma->anon_name memory leak for anonymous shmem VMAs | expand |
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?
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?
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.
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>
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
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 --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,
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(-)