Miles Chen
3d29e6420b
mm/memcontrol.c: fix use after free in mem_cgroup_iter()
...
commit 54a83d6bcbf8f4700013766b974bf9190d40b689 upstream.
This patch is sent to report an use after free in mem_cgroup_iter()
after merging commit be2657752e9e ("mm: memcg: fix use after free in
mem_cgroup_iter()").
I work with android kernel tree (4.9 & 4.14), and commit be2657752e9e
("mm: memcg: fix use after free in mem_cgroup_iter()") has been merged
to the trees. However, I can still observe use after free issues
addressed in the commit be2657752e9e. (on low-end devices, a few times
this month)
backtrace:
css_tryget <- crash here
mem_cgroup_iter
shrink_node
shrink_zones
do_try_to_free_pages
try_to_free_pages
__perform_reclaim
__alloc_pages_direct_reclaim
__alloc_pages_slowpath
__alloc_pages_nodemask
To debug, I poisoned mem_cgroup before freeing it:
static void __mem_cgroup_free(struct mem_cgroup *memcg)
for_each_node(node)
free_mem_cgroup_per_node_info(memcg, node);
free_percpu(memcg->stat);
+ /* poison memcg before freeing it */
+ memset(memcg, 0x78, sizeof(struct mem_cgroup));
kfree(memcg);
}
The coredump shows the position=0xdbbc2a00 is freed.
(gdb) p/x ((struct mem_cgroup_per_node *)0xe5009e00)->iter[8]
$13 = {position = 0xdbbc2a00, generation = 0x2efd}
0xdbbc2a00: 0xdbbc2e00 0x00000000 0xdbbc2800 0x00000100
0xdbbc2a10: 0x00000200 0x78787878 0x00026218 0x00000000
0xdbbc2a20: 0xdcad6000 0x00000001 0x78787800 0x00000000
0xdbbc2a30: 0x78780000 0x00000000 0x0068fb84 0x78787878
0xdbbc2a40: 0x78787878 0x78787878 0x78787878 0xe3fa5cc0
0xdbbc2a50: 0x78787878 0x78787878 0x00000000 0x00000000
0xdbbc2a60: 0x00000000 0x00000000 0x00000000 0x00000000
0xdbbc2a70: 0x00000000 0x00000000 0x00000000 0x00000000
0xdbbc2a80: 0x00000000 0x00000000 0x00000000 0x00000000
0xdbbc2a90: 0x00000001 0x00000000 0x00000000 0x00100000
0xdbbc2aa0: 0x00000001 0xdbbc2ac8 0x00000000 0x00000000
0xdbbc2ab0: 0x00000000 0x00000000 0x00000000 0x00000000
0xdbbc2ac0: 0x00000000 0x00000000 0xe5b02618 0x00001000
0xdbbc2ad0: 0x00000000 0x78787878 0x78787878 0x78787878
0xdbbc2ae0: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2af0: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b00: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b10: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b20: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b30: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b40: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b50: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b60: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b70: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2b80: 0x78787878 0x78787878 0x00000000 0x78787878
0xdbbc2b90: 0x78787878 0x78787878 0x78787878 0x78787878
0xdbbc2ba0: 0x78787878 0x78787878 0x78787878 0x78787878
In the reclaim path, try_to_free_pages() does not setup
sc.target_mem_cgroup and sc is passed to do_try_to_free_pages(), ...,
shrink_node().
In mem_cgroup_iter(), root is set to root_mem_cgroup because
sc->target_mem_cgroup is NULL. It is possible to assign a memcg to
root_mem_cgroup.nodeinfo.iter in mem_cgroup_iter().
try_to_free_pages
struct scan_control sc = {...}, target_mem_cgroup is 0x0;
do_try_to_free_pages
shrink_zones
shrink_node
mem_cgroup *root = sc->target_mem_cgroup;
memcg = mem_cgroup_iter(root, NULL, &reclaim);
mem_cgroup_iter()
if (!root)
root = root_mem_cgroup;
...
css = css_next_descendant_pre(css, &root->css);
memcg = mem_cgroup_from_css(css);
cmpxchg(&iter->position, pos, memcg);
My device uses memcg non-hierarchical mode. When we release a memcg:
invalidate_reclaim_iterators() reaches only dead_memcg and its parents.
If non-hierarchical mode is used, invalidate_reclaim_iterators() never
reaches root_mem_cgroup.
static void invalidate_reclaim_iterators(struct mem_cgroup *dead_memcg)
{
struct mem_cgroup *memcg = dead_memcg;
for (; memcg; memcg = parent_mem_cgroup(memcg)
...
}
So the use after free scenario looks like:
CPU1 CPU2
try_to_free_pages
do_try_to_free_pages
shrink_zones
shrink_node
mem_cgroup_iter()
if (!root)
root = root_mem_cgroup;
...
css = css_next_descendant_pre(css, &root->css);
memcg = mem_cgroup_from_css(css);
cmpxchg(&iter->position, pos, memcg);
invalidate_reclaim_iterators(memcg);
...
__mem_cgroup_free()
kfree(memcg);
try_to_free_pages
do_try_to_free_pages
shrink_zones
shrink_node
mem_cgroup_iter()
if (!root)
root = root_mem_cgroup;
...
mz = mem_cgroup_nodeinfo(root, reclaim->pgdat->node_id);
iter = &mz->iter[reclaim->priority];
pos = READ_ONCE(iter->position);
css_tryget(&pos->css) <- use after free
To avoid this, we should also invalidate root_mem_cgroup.nodeinfo.iter
in invalidate_reclaim_iterators().
[cai@lca.pw: fix -Wparentheses compilation warning]
Link: http://lkml.kernel.org/r/1564580753-17531-1-git-send-email-cai@lca.pw
Link: http://lkml.kernel.org/r/20190730015729.4406-1-miles.chen@mediatek.com
Fixes: 5ac8fb31ad2e ("mm: memcontrol: convert reclaim iterator to simple css refcounting")
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
Signed-off-by: Qian Cai <cai@lca.pw>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-25 10:52:56 +02:00
..
2018-08-24 13:26:58 +02:00
2019-06-11 12:23:41 +02:00
2016-03-03 15:07:18 -08:00
2015-09-08 15:35:28 -07:00
2015-04-14 16:49:03 -07:00
2019-06-22 08:18:18 +02:00
2019-08-06 18:28:27 +02:00
2015-08-14 15:56:32 -07:00
2018-01-17 09:35:26 +01:00
2017-11-24 11:26:29 +01:00
2018-09-19 22:49:00 +02:00
2015-11-06 17:50:42 -08:00
2018-02-25 11:03:41 +01:00
2018-09-15 09:40:38 +02:00
2015-11-06 17:50:42 -08:00
2018-05-26 08:48:54 +02:00
2018-12-17 21:55:16 +01:00
2015-06-24 17:49:45 -07:00
2018-12-17 21:55:17 +01:00
2014-08-06 18:01:22 -07:00
2018-11-10 07:41:42 -08:00
2015-11-06 17:50:42 -08:00
2019-06-22 08:18:17 +02:00
2015-09-10 13:29:01 -07:00
2017-01-06 11:16:11 +01:00
2017-08-11 09:08:50 -07:00
2015-02-10 14:30:31 -08:00
2018-05-26 08:48:55 +02:00
2015-01-08 15:10:52 -08:00
2014-10-09 22:25:50 -04:00
2019-08-04 09:34:59 +02:00
2018-05-30 07:49:08 +02:00
2019-06-22 08:18:22 +02:00
2015-11-05 19:34:48 -08:00
2018-10-10 08:52:11 +02:00
2015-09-11 16:42:39 -07:00
2017-06-14 13:16:26 +02:00
2019-08-25 10:52:56 +02:00
2019-03-23 08:44:26 +01:00
2018-01-31 12:06:09 +01:00
2018-12-17 21:55:17 +01:00
2019-04-27 09:33:47 +02:00
2017-08-12 19:29:09 -07:00
2015-09-08 15:35:28 -07:00
2019-03-23 08:44:23 +01:00
2019-06-11 12:23:36 +02:00
2018-12-13 09:21:33 +01:00
2015-06-30 19:44:56 -07:00
2019-06-22 08:18:27 +02:00
2017-12-25 14:22:09 +01:00
2019-08-04 09:34:59 +02:00
2015-02-11 17:06:02 -08:00
2018-08-15 17:42:10 +02:00
2018-11-10 07:41:42 -08:00
2015-11-05 19:34:48 -08:00
2015-06-30 19:44:55 -07:00
2018-12-17 21:55:17 +01:00
2019-02-06 19:43:07 +01:00
2018-07-11 16:03:51 +02:00
2015-11-05 19:34:48 -08:00
2019-04-27 09:33:48 +02:00
2019-07-10 09:56:30 +02:00
2015-08-13 12:32:00 -06:00
2016-04-20 15:41:53 +09:00
2017-11-24 08:32:25 +01:00
2019-01-26 09:42:55 +01:00
2017-11-24 08:32:25 +01:00
2014-09-02 14:46:05 -04:00
2014-09-02 14:46:02 -04:00
2018-05-16 10:06:46 +02:00
2016-02-25 12:01:23 -08:00
2018-12-17 21:55:16 +01:00
2015-11-06 17:50:42 -08:00
2019-04-03 06:23:18 +02:00
2019-03-23 08:44:34 +01:00
2017-10-21 17:09:05 +02:00
2019-04-27 09:33:48 +02:00
2015-11-22 11:58:44 -08:00
2015-11-22 11:58:44 -08:00
2018-10-10 08:52:08 +02:00
2017-07-05 14:37:15 +02:00
2015-09-08 15:35:28 -07:00
2015-11-06 17:50:42 -08:00
2018-08-15 17:42:10 +02:00
2018-12-13 09:21:33 +01:00
2015-09-04 16:54:41 -07:00
2018-12-17 21:55:16 +01:00
2018-09-19 22:49:00 +02:00
2019-08-25 10:52:44 +02:00
2017-03-12 06:37:25 +01:00
2018-06-06 16:46:23 +02:00
2019-08-04 09:35:01 +02:00
2016-10-28 03:01:34 -04:00
2015-11-06 17:50:42 -08:00
2015-11-06 17:50:42 -08:00
2016-05-18 17:06:44 -07:00
2018-09-05 09:18:36 +02:00