[PATCH v2] mm: memcg/slab: Fix use after free in obj_cgroup_charge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The rcu_read_lock/unlock only can guarantee that the memcg will
not be freed, but it cannot guarantee the success of css_get to
memcg.

If the whole process of a cgroup offlining is completed between
reading a objcg->memcg pointer and bumping the css reference on
another CPU, and there are exactly 0 external references to this
memory cgroup (how we get to the obj_cgroup_charge() then?),
css_get() can change the ref counter from 0 back to 1.

Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API")
Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
Acked-by: Roman Gushchin <guro@xxxxxx>
---
 changelog in v2:
 1. Add unlikely and update the commit log suggested by Roman.

 mm/memcontrol.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8c8b4c3ed5a0..d9cdf899c6fc 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3221,8 +3221,10 @@ int obj_cgroup_charge(struct obj_cgroup *objcg, gfp_t gfp, size_t size)
 	 * independently later.
 	 */
 	rcu_read_lock();
+retry:
 	memcg = obj_cgroup_memcg(objcg);
-	css_get(&memcg->css);
+	if (unlikely(!css_tryget(&memcg->css)))
+		goto retry;
 	rcu_read_unlock();
 
 	nr_pages = size >> PAGE_SHIFT;
-- 
2.20.1





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux