All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Bouchinet <nicolas.bouchinet@clip-os.org>
To: Xiongwei Song <sxwjean@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, cl@linux.com,
	penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
	akpm@linux-foundation.org, vbabka@suse.cz,
	roman.gushchin@linux.dev, 42.hyeyoo@gmail.com
Subject: Re: [PATCH] slub: Fixes freepointer encoding for single free
Date: Mon, 29 Apr 2024 09:55:55 +0200	[thread overview]
Message-ID: <1136cf64-c1b6-4909-b64e-0c754276024c@clip-os.org> (raw)
In-Reply-To: <CAEVVKH9rwS6vR5_AjHyjS0vknyZvHabooE+c+k_5XNn2Rdac6w@mail.gmail.com>


On 4/26/24 15:14, Xiongwei Song wrote:
> On Fri, Apr 26, 2024 at 8:18 PM Nicolas Bouchinet
> <nicolas.bouchinet@clip-os.org> wrote:
>> On 4/26/24 11:20, Xiongwei Song wrote:
>>> On Wed, Apr 24, 2024 at 8:48 PM Nicolas Bouchinet
>>> <nicolas.bouchinet@clip-os.org> wrote:
>>>> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>>>>
>>>> Commit 284f17ac13fe ("mm/slub: handle bulk and single object freeing
>>>> separately") splits single and bulk object freeing in two functions
>>>> slab_free() and slab_free_bulk() which leads slab_free() to call
>>>> slab_free_hook() directly instead of slab_free_freelist_hook().
>>>>
>>>> If `init_on_free` is set, slab_free_hook() zeroes the object.
>>>> Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are
>>>> set, the do_slab_free() slowpath executes freelist consistency
>>>> checks and try to decode a zeroed freepointer which leads to a
>>>> "Freepointer corrupt" detection in check_object().
>>>>
>>>> Object's freepointer thus needs to be properly set using
>>>> set_freepointer() after init_on_free.
>>>>
>>>> To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the
>>>> command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`.
>>>>
>>>> dmesg sample log:
>>>> [   10.708715] =============================================================================
>>>> [   10.710323] BUG kmalloc-rnd-05-32 (Tainted: G    B           T ): Freepointer corrupt
>>>> [   10.712695] -----------------------------------------------------------------------------
>>>> [   10.712695]
>>>> [   10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2)
>>>> [   10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c
>>> If init_on_free is set,  slab_free_hook() zeros the object first, then
>>> do_slab_free() calls
>>> set_freepointer() to set the fp value, so there are 8 bytes non-zero
>>> at the moment?
>>> Hence, the issue is not related to init_on_free?
>>>
>>> The fp=0x7ee4f480ce0ecd7c here is beyond kernel memory space, is the issue from
>>> CONFIG_SLAB_FREELIST_HARDENED enabled?
>> My understanding of the bug is that slab_free_hook() indeed zeroes the
>> object and its metadata first, then calls do_slab_free() and directly
>> calls __slab_free(), head an tail parameters being set to the object.
>>
>> If `slub_debug=F` (SLAB_CONSISTENCY_CHECKS) is set, the following call
>> path can be executed :
>>
>> free_to_partial_list() ->
>>
>> free_debug_processing() ->
>>
>> free_consistency_checks() ->
>>
>> check_object() ->
>>
>> check_valid_pointer(get_freepointer())
> I understand the call path. I meant here the freepointer is not ZERO
> but an illegal
> value( fp=0x7ee4f480ce0ecd7c),


Yes this is the reason of this patch. The freepointer is an illegal 
value because the memory range where it sits has been overridden by 
zeroes, set_freepointer() is never called and thus the freepointer is 
never properly set.


  The illegal value is obtained after zeroes has been decoded by 
get_freepointer()->freelist_ptr_decode().


>   then check_valid_pointer return 1 with
> it's last line
> and then check_object() printed out the error message. I'm not sure if I
> misunderstood you.


check_valid_pointer() returns 0 since object < base, the object being 
the decoded fp (0x7ee4f480ce0ecd7c < 0xffff.* base addr), hence 
check_object() returns 0, not 1.

This is why the "Object at 0x%p not freed" slab_fix() is called in 
free_debug_processing().


>
> Thank,
> Xiongwei
>

      reply	other threads:[~2024-04-29  7:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24 12:47 [PATCH] slub: Fixes freepointer encoding for single free Nicolas Bouchinet
2024-04-25  8:36 ` Chengming Zhou
2024-04-25 15:02   ` Nicolas Bouchinet
2024-04-25 15:14     ` Chengming Zhou
2024-04-29  8:52       ` Vlastimil Babka
2024-04-29  9:09         ` Nicolas Bouchinet
2024-04-29 12:59           ` Nicolas Bouchinet
2024-04-29 13:35             ` Chengming Zhou
2024-04-29 14:32               ` Nicolas Bouchinet
2024-04-29 14:52                 ` Chengming Zhou
2024-04-29 16:16                   ` Nicolas Bouchinet
2024-04-29 20:22                     ` Vlastimil Babka
2024-04-30  9:19                       ` Nicolas Bouchinet
2024-04-26  9:20 ` Xiongwei Song
2024-04-26 12:18   ` Nicolas Bouchinet
2024-04-26 13:14     ` Xiongwei Song
2024-04-29  7:55       ` Nicolas Bouchinet [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1136cf64-c1b6-4909-b64e-0c754276024c@clip-os.org \
    --to=nicolas.bouchinet@clip-os.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=sxwjean@gmail.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.