linux-kernel - Re: [PATCH] mm: list_lru: fix UAF for memory cgroup

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

Message-Id: <F44A592F-15BF-4406-A073-9CF7741956A0@linux.dev>
Date: Thu, 1 Aug 2024 10:42:31 +0800
From: Muchun Song <muchun.song@...ux.dev>
To: "Vlastimil Babka (SUSE)" <vbabka@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Muchun Song <songmuchun@...edance.com>,
 Johannes Weiner <hannes@...xchg.org>,
 Nhat Pham <nphamcs@...il.com>,
 Linux Memory Management List <linux-mm@...ck.org>,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: list_lru: fix UAF for memory cgroup



> On Jul 31, 2024, at 18:06, Vlastimil Babka (SUSE) <vbabka@...nel.org> wrote:
> 
> On 7/24/24 4:23 AM, Muchun Song wrote:
>> 
>> 
>>> On Jul 24, 2024, at 08:45, Andrew Morton <akpm@...ux-foundation.org> wrote:
>>> 
>>> On Thu, 18 Jul 2024 16:36:07 +0800 Muchun Song <songmuchun@...edance.com> wrote:
>>> 
>>>> The mem_cgroup_from_slab_obj() is supposed to be called under rcu
>>>> lock or cgroup_mutex or others which could prevent returned memcg
>>>> from being freed. Fix it by adding missing rcu read lock.
>>> 
>>> "or others" is rather vague.  What others?
>> 
>> Like objcg_lock. I have added this one into obj_cgroup_memcg().
>> 
>>> 
>>>> @@ -109,14 +110,20 @@ EXPORT_SYMBOL_GPL(list_lru_add);
>>>> 
>>>> bool list_lru_add_obj(struct list_lru *lru, struct list_head *item)
>>>> {
>>>> +  bool ret;
>>>> int nid = page_to_nid(virt_to_page(item));
>>>> -  struct mem_cgroup *memcg = list_lru_memcg_aware(lru) ?
>>>> -  mem_cgroup_from_slab_obj(item) : NULL;
>>>> +  struct mem_cgroup *memcg;
>>>> 
>>>> -  return list_lru_add(lru, item, nid, memcg);
>>>> +  rcu_read_lock();
>>>> +  memcg = list_lru_memcg_aware(lru) ? mem_cgroup_from_slab_obj(item) : NULL;
>>>> +  ret = list_lru_add(lru, item, nid, memcg);
>>>> +  rcu_read_unlock();
>>> 
>>> We don't need rcu_read_lock() to evaluate NULL.
>>> 
>>> memcg = NULL;
>>> if (list_lru_memcg_aware(lru)) {
>>> rcu_read_lock();
>>> memcg = mem_cgroup_from_slab_obj(item);
>>> rcu_read_unlock();
>> 
>> Actually, the access to memcg is in list_lru_add(), so the rcu lock should
>> also cover this function rather than only mem_cgroup_from_slab_obj().
>> Something like:
>> 
>> memcg = NULL;
>> if (list_lru_memcg_aware(lru)) {
>> rcu_read_lock();
>> memcg = mem_cgroup_from_slab_obj(item);
>> }
>> ret = list_lru_add(lru, item, nid, memcg);
>> if (list_lru_memcg_aware(lru))
>> rcu_read_unlock();
>> 
>> Not concise. I don't know if this is good.
> 
> At such point, it's probably best to just:
> 
> if (list_lru_memcg_aware(lru)) {
> 	rcu_read_lock();
> 	ret = list_lru_add(lru, item, nid, mem_cgroup_from_slab_obj(item));
> 	rcu_read_unlock();
> } else {
> 	list_lru_add(lru, item, nid, NULL);
> }

Good. Will update v2.

Thanks.

> 
> ?
> 
>> 
>>> }
>>> 
>>> Seems worthwhile?