| Message ID | 20201028035013.99711-2-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] mm: memcg/slab: Fix use after free in obj_cgroup_charge | expand |
On Tue, Oct 27, 2020 at 8:51 PM Muchun Song <songmuchun@bytedance.com> wrote: > > 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@bytedance.com> > Acked-by: Roman Gushchin <guro@fb.com> Reviewed-by: Shakeel Butt <shakeelb@google.com>
On Wed, Oct 28, 2020 at 11:50 AM Muchun Song <songmuchun@bytedance.com> wrote: > > 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@bytedance.com> > Acked-by: Roman Gushchin <guro@fb.com> Hi Andrew, Maybe you forgot to add this to the queue for the merge window? Thanks. > --- > 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 > -- Yours, Muchun
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;
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@bytedance.com> Acked-by: Roman Gushchin <guro@fb.com> --- 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(-)