linux-kernel - Re: [PATCH] mm: memcg: fix NULL pointer in mem_cgroup_track_foreign

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] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 29 Jan 2023 13:48:15 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Kefeng Wang <wangkefeng.wang@...wei.com>
Cc:     Tejun Heo <tj@...nel.org>, Jens Axboe <axboe@...nel.dk>,
        Jan Kara <jack@...e.cz>, Shakeel Butt <shakeelb@...gle.com>,
        Naoya Horiguchi <naoya.horiguchi@....com>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        Ma Wupeng <mawupeng1@...wei.com>,
        Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] mm: memcg: fix NULL pointer in
 mem_cgroup_track_foreign_dirty()

On Sun, 29 Jan 2023 10:44:51 +0800 Kefeng Wang <wangkefeng.wang@...wei.com> wrote:

> As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"),

Merged in 2017.

> hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg
> could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could
> occurs a NULL pointer dereference, let's do not record the foreign
> writebacks for folio memcg is null in mem_cgroup_track_foreign() to
> fix it.
> 
> Reported-by: Ma Wupeng <mawupeng1@...wei.com>
> Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing")

Merged in 2019.

> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -1688,10 +1688,13 @@ void mem_cgroup_track_foreign_dirty_slowpath(struct folio *folio,
>  static inline void mem_cgroup_track_foreign_dirty(struct folio *folio,
>  						  struct bdi_writeback *wb)
>  {
> +	struct mem_cgroup *memcg;
> +
>  	if (mem_cgroup_disabled())
>  		return;
>  
> -	if (unlikely(&folio_memcg(folio)->css != wb->memcg_css))
> +	memcg = folio_memcg(folio);
> +	if (unlikely(memcg && &memcg->css != wb->memcg_css))
>  		mem_cgroup_track_foreign_dirty_slowpath(folio, wb);
>  }

Has this null deref actually been observed, or is this from code
inspection?  (This is why it's nice to include the Link: after a
Reported-by!)

Do we have any theories why this took so many years to surface?

I'm confused about the mention of 18365225f044, but the Fixes: target
is a different commit.  Please explain this?

Do you think the fix should be backported into earlier -stable kernels?
If so, it will need some rework due to the subsequent folio
conversion.