From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 613E6C4345F for ; Tue, 30 Apr 2024 09:20:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C38C06B0088; Tue, 30 Apr 2024 05:20:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE9696B0089; Tue, 30 Apr 2024 05:20:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD6EC6B008C; Tue, 30 Apr 2024 05:20:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8CF166B0088 for ; Tue, 30 Apr 2024 05:20:06 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3791F1C0CED for ; Tue, 30 Apr 2024 09:20:06 +0000 (UTC) X-FDA: 82065651612.27.BAB1CCC Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by imf04.hostedemail.com (Postfix) with ESMTP id 0BDCA4001B for ; Tue, 30 Apr 2024 09:20:03 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=clip-os.org header.s=gm1 header.b=k8QJX1bT; spf=pass (imf04.hostedemail.com: domain of nicolas.bouchinet@clip-os.org designates 217.70.183.200 as permitted sender) smtp.mailfrom=nicolas.bouchinet@clip-os.org; dmarc=pass (policy=none) header.from=clip-os.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714468804; a=rsa-sha256; cv=none; b=1eevKwEkLHW6fS1VCOP8PDDt75I07er4knoRiqgNmWFDGuqz9G2DEutPavPROOiavtebsg lsi6y6xmOlqAEU4wqR8XBH5GqENfCwpBR5Qy2dVly2e14Kk9rQrL14cTdzdUxG0O/+VVO5 3IvAUS0Ra8hlWxQBeyaFvGS5UiRhO4Q= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=clip-os.org header.s=gm1 header.b=k8QJX1bT; spf=pass (imf04.hostedemail.com: domain of nicolas.bouchinet@clip-os.org designates 217.70.183.200 as permitted sender) smtp.mailfrom=nicolas.bouchinet@clip-os.org; dmarc=pass (policy=none) header.from=clip-os.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714468804; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=E5WI2wQDSf6+iCnD2XmajtzE8LnfA93T1JMzMZ7UZ4Q=; b=V9vkQFMgiioMGXyLYXq+TypqhrvjwCAEwDxVBZkKv53UXkjXpAHmBdOKIKXpGLs0CMdGRI Tdy8jIl1Az03t38dda8AQtxUbWyg3XBw31V5CHCL1JHD4g4vPV0un0S7dyOqAOkciKEOBs u68V6lyN9xMh56pBb+L8XCx4/uIRXUE= Received: by mail.gandi.net (Postfix) with ESMTPSA id C1D1B2000D; Tue, 30 Apr 2024 09:19:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clip-os.org; s=gm1; t=1714468802; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E5WI2wQDSf6+iCnD2XmajtzE8LnfA93T1JMzMZ7UZ4Q=; b=k8QJX1bTdcXE4cJQ12Yp4hGl72YKOCpxnFiZSPIosSmeiGQBE75l/W8K2xi9hp9PGJ/uMl e9Ir/YBilXS39SVhWuIE/2/LUghCqSchXzzz6iWX6eg5ef5UEAP6BsrR95atEsW7zCEJqo 68+5/rJZQjy73mUHKtTALivJF8C2H6uBa+Bhy7OrxyCg9qA6qICDfyQiL25eCVJL1BanBi ntPvQ8hBf2avHUFbp9TWMHaoZuUZGgPsKoOUXR06Hw1xHK5YEXG1mxtaUBOjVSJa3/KlQM c3pS8RCW3ZXJ99tAuI2onNFUPGmgI4vz2n6oV8ri1ZhZTvip1K8CvZG+wnhhnA== Message-ID: <28095247-b28d-47f9-a28c-775432d2d6d3@clip-os.org> Date: Tue, 30 Apr 2024 11:19:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] slub: Fixes freepointer encoding for single free To: Vlastimil Babka , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, Xiongwei Song References: <5c34b253-b476-494a-96c9-fe3c95b9b74d@linux.dev> <6f977874-2a18-44ef-b207-9eb0baad9d66@suse.cz> <7074c0b4-62d4-444d-8e59-e23bbbccf9b8@clip-os.org> <83fda406-0340-4b7b-9f02-e9eb41c77f0e@clip-os.org> <73f80886-e390-4320-84dd-68e7cd7e8c62@linux.dev> <10c9a07a-1c6d-4ea7-8c1d-03a7dc5b29d8@clip-os.org> Content-Language: en-US From: Nicolas Bouchinet In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-GND-Sasl: nicolas.bouchinet@clip-os.org X-Stat-Signature: scnq4wwaeobceawyr5jnga7ru4qdtswt X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0BDCA4001B X-HE-Tag: 1714468803-294895 X-HE-Meta: U2FsdGVkX1/RhO/gvI1eddeOEoiUHAl7WuM98cFeZBScW+55kAy4gAafRy+gZwjVCz7X+CDT1VV7AP2yYqwsKt6CqhFSwwZCj3UlQ7rEbp8oVeGzSs1/KONoGIMijiQEREYuLiBZQm8jDJAsDty/pV9naQzhaGa1OqTl9c2lEVdqoFUwZU1mlZAFMl56fKSfXeVjq0aVcZmo4ZJqNLcPRcSxOBV7FmqpC8q4j5O+/tRyLpmxaFt6NPbA7kq66jVLP4ZRI0WYj3LXO+NA08xpdZD7RMCi01vlvOy5+prR16OQNhho8cx7PL8EgGxxx7KXH2gow1J/leU877WMYTQAM4DHWkqQaEM6mIWXhtGhh+TyTVzH/8oKEhtEcIe3MzhIWq/ogg1Brm6kH7XEIe8BvdkYPBqTbrUnPlOvHrdgKK2ni2h0LMrnszPQFAX6WrIiJ3w2v9/9rpAsvOXCWu/Ru8tQm2L5xtwyTVPpPGgv6g8sParn6yR7krBY3QQ/LPIMFczt3ySFap0bgM3ZJcHBCOtsiXya0bpQjnn0LL1K568gnbv34pW054az7wdzWSSqIeAilXZ7x84rXYt3Voxx3Ne5F09+b79SzJoRKwLP38pr5+BUt1IMcU4mSvyrKlejnEcg31FXo/CscT1Ano4ZORPr2xqCjE3Fzj/NvmGGjsC2Atdnpi2lJqQnwUT+5F7Gz5X1XI2MYeI+vjso6ka8YswRTZNFg5LTYQ1B6UBIbW74KoD/tHeenoCpKpJvzOTyXYqnR8FaR0cZefJXQjKQe7zTQlxzGcz8Pp0x2orTpzpcPWL8D861+8hxAMF9Ql04NIudasLLtLXYhwM1JkyCr4WmG4s9wmlPT11VZs3OiLJ3CQROV59Oi7Nyr7JPloM5OfTtApFi98KWAiWGf18hGpCRokzrKhL0OIOI3bE+InxPJaqr+JSCusa+yLRPX2aJeID9oIASowdE5fuWmdz I8Pl3gnM zkH6ov6/v6Z776VxIWRRg7hMnxYtXcTI+9NQIme6gzB2IlrkOmAG76jGT4MnvFFUUlFYlBdQxtl9s2ZnnZb69YE0Lprx+K6d/+CM8RzEWOt8ue7fEMMtEy6ZUQeb5PKQ1L0Rn9lzSiv+Wg6m+pPnGC+SDltGfO0aLo8dQ4AqAwrBVzVK//orzUK3Ax33vyRY0ctv/yY0Xcnn9VaAGOv0WJW5XdUM3eGSdVhJsGndAtpZR+oonqVTnvJM+syi5YrZ6qZIMPKpk1/fCwOZB7BCFtUyUWA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 4/29/24 22:22, Vlastimil Babka wrote: > On 4/29/24 6:16 PM, Nicolas Bouchinet wrote: >> On 4/29/24 16:52, Chengming Zhou wrote: >>> On 2024/4/29 22:32, Nicolas Bouchinet wrote: >>>> On 4/29/24 15:35, Chengming Zhou wrote: >>>>> On 2024/4/29 20:59, Nicolas Bouchinet wrote: >>>>>>> I help maintaining the Linux-Hardened patchset in which we have a slab object canary feature that helps detecting overflows. It is located just after the object freepointer. >>>>>> I've tried a patch where the freepointer is avoided but it results in the same bug. It seems that the commit 0f181f9fbea8bc7ea ("mm/slub.c: init_on_free=1 should wipe freelist ptr for bulk allocations") inits the freepointer on allocation if init_on_free is set in order to return a clean initialized object to the caller. >>>>>> >>>>> Good catch! You may need to change maybe_wipe_obj_freeptr() too, >>>>> I haven't tested this, not sure whether it works for you. :) >>>>> >>>>> diff --git a/mm/slub.c b/mm/slub.c >>>>> index 3e33ff900d35..3f250a167cb5 100644 >>>>> --- a/mm/slub.c >>>>> +++ b/mm/slub.c >>>>> @@ -3796,7 +3796,8 @@ static void *__slab_alloc_node(struct kmem_cache *s, >>>>>   static __always_inline void maybe_wipe_obj_freeptr(struct kmem_cache *s, >>>>>                                                     void *obj) >>>>>   { >>>>> -       if (unlikely(slab_want_init_on_free(s)) && obj) >>>>> +       if (unlikely(slab_want_init_on_free(s)) && obj && >>>>> +           !freeptr_outside_object(s)) >>>>>                  memset((void *)((char *)kasan_reset_tag(obj) + s->offset), >>>>>                          0, sizeof(void *)); >>>>>   } >>>>> >>>>> Thanks! >>>> Indeed since check_object() avoids objects for which freepointer is in the object and since val is equal to SLUB_RED_ACTIVE in our specific case it should work. Do you want me to add you as Co-authored ? >>>> >>> Ok, it's great. Thanks! >> Now I think of it, doesn't it seems a bit odd to only properly >> init_on_free object's freepointer only if it's inside the object ? IMHO >> it is equally necessary to avoid information leaking about the >> freepointer whether it is inside or outside the object. >> I think it break the semantic of the commit 0f181f9fbea8bc7ea >> ("mm/slub.c: init_on_free=1 should wipe freelist ptr for bulk >> allocations") ? > Hm, AFAIU, wiping inside object prevents misuse of some buggy kernel code > that would allocate and accidentally leak prior content (including the > in-object freepointer) somewhere the attacker can read. Now for wiping the > freepointer outside the object to be useful it would have assume said > leak-prone code to additionally be reading past the allocated object size, > i.e. a read buffer overflow. That to me seems to be a much more rare > combination, and also in that case such code could also likely read even > further past the object, i.e. leak the next object's data? IOW I don't think > it buys us much additional security protection in practice? > Moreover, with CONFIG_SLAB_FREELIST_HARDENED activated, freepointers are encoded and harder to exploit. >> Thanks. >> >