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:	Fri, 1 Jul 2016 16:15:20 +0200
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Joonsoo Kim <js1304@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Alexander Potapenko <glider@...gle.com>,
	kasan-dev <kasan-dev@...glegroups.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [PATCH v3] kasan/quarantine: fix bugs on qlist_move_cache()

On Fri, Jul 1, 2016 at 4:09 PM, Joonsoo Kim <js1304@...il.com> wrote:
> 2016-07-01 23:03 GMT+09:00 Dmitry Vyukov <dvyukov@...gle.com>:
>> On Fri, Jul 1, 2016 at 4:02 PM,  <js1304@...il.com> wrote:
>>> From: Joonsoo Kim <iamjoonsoo.kim@....com>
>>>
>>> There are two bugs on qlist_move_cache(). One is that qlist's tail
>>> isn't set properly. curr->next can be NULL since it is singly linked
>>> list and NULL value on tail is invalid if there is one item on qlist.
>>> Another one is that if cache is matched, qlist_put() is called and
>>> it will set curr->next to NULL. It would cause to stop the loop
>>> prematurely.
>>>
>>> These problems come from complicated implementation so I'd like to
>>> re-implement it completely. Implementation in this patch is really
>>> simple. Iterate all qlist_nodes and put them to appropriate list.
>>>
>>> Unfortunately, I got this bug sometime ago and lose oops message.
>>> But, the bug looks trivial and no need to attach oops.
>>>
>>> v3: fix build warning
>>>
>>> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@....com>
>>> ---
>>>  mm/kasan/quarantine.c | 21 +++++++--------------
>>>  1 file changed, 7 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
>>> index 4973505..cf92494 100644
>>> --- a/mm/kasan/quarantine.c
>>> +++ b/mm/kasan/quarantine.c
>>> @@ -238,30 +238,23 @@ static void qlist_move_cache(struct qlist_head *from,
>>>                                    struct qlist_head *to,
>>>                                    struct kmem_cache *cache)
>>>  {
>>> -       struct qlist_node *prev = NULL, *curr;
>>> +       struct qlist_node *curr;
>>>
>>>         if (unlikely(qlist_empty(from)))
>>>                 return;
>>>
>>>         curr = from->head;
>>> +       qlist_init(from);
>>>         while (curr) {
>>>                 struct qlist_node *qlink = curr;
>>>                 struct kmem_cache *obj_cache = qlink_to_cache(qlink);
>>>
>>> -               if (obj_cache == cache) {
>>> -                       if (unlikely(from->head == qlink)) {
>>> -                               from->head = curr->next;
>>> -                               prev = curr;
>>> -                       } else
>>> -                               prev->next = curr->next;
>>> -                       if (unlikely(from->tail == qlink))
>>> -                               from->tail = curr->next;
>>> -                       from->bytes -= cache->size;
>>> -                       qlist_put(to, qlink, cache->size);
>>> -               } else {
>>> -                       prev = curr;
>>> -               }
>>>                 curr = curr->next;
>>> +
>>> +               if (obj_cache == cache)
>>> +                       qlist_put(to, qlink, cache->size);
>>> +               else
>>> +                       qlist_put(from, qlink, cache->size);
>>
>> This line is wrong. If obj_cache != cache, object size != cache->size.
>> Quarantine contains objects of different sizes.
>
> You're right. 11 pm is not good time to work. :/
> If it is fixed, the patch looks correct to you?
> I will fix it and send v4 on next week.


I don't see anything else wrong. But I need to see how you fix the size issue.
Performance of this operation is not particularly critical, so the
simpler the better.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ