public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Xingyu Li <xli399@ucr.edu>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Cc: Yu Hao <yhao016@ucr.edu>
Subject: Re: BUG: general protection fault in __free_object
Date: Mon, 02 Sep 2024 11:21:11 +0200	[thread overview]
Message-ID: <87frqi76ns.ffs@tglx> (raw)
In-Reply-To: <CALAgD-7TsMdA7rjxfpheXc=MNqikEXY9TZNxJt4z9vm6Yfs5qQ@mail.gmail.com>

On Wed, Aug 28 2024 at 16:27, Xingyu Li wrote:
> We found a bug in Linux 6.10 using syzkaller. It is possibly a null
> pointer dereference  bug.
> The reproducer is
> https://gist.github.com/freexxxyyy/5aefd53c6567415e9fe8c76cc2ad390c

Reproducer alone is not really helpful. This needs the corresponding
kernel config, the exact kernel version and a description of the
reproduction environment (compiler, qemu command line ....)

It does not reproduce here at all.

Also if it really reproduces, then have you checked against current
mainline as well?

> RIP: 0010:hlist_add_head include/linux/list.h:1032 [inline]
> RIP: 0010:__free_object+0x903/0xaa0 lib/debugobjects.c:396
>  __debug_check_no_obj_freed lib/debugobjects.c:994 [inline]
>  debug_check_no_obj_freed+0x135/0x530 lib/debugobjects.c:1019
>  slab_free_hook mm/slub.c:2163 [inline]
>  slab_free_freelist_hook mm/slub.c:2225 [inline]
>  slab_free_bulk mm/slub.c:4462 [inline]
>  kmem_cache_free_bulk+0x1bf/0x360 mm/slub.c:4676

The code in question is serialized against objpool modifications with
pool_lock. So nothing can change any of the related data.

    if (obj_pool_free > debug_objects_pool_size &&
        obj_nr_tofree < ODEBUG_FREE_WORK_MAX) {

	for (i = 0; i < ODEBUG_BATCH_SIZE; i++) {
		obj = __alloc_object(&obj_pool);
		hlist_add_head(&obj->node, &obj_to_free); <- fail

debug_objects_pool_size is initialized to:

        ODEBUG_POOL_SIZE + num_possible_cpus() * ODEBUG_BATCH_SIZE;
=
        1024 + num_possible_cpus() * 16

The minimum size is 1040, so there are at least 1040 objects in
obj_pool. The loop allocates at max 16 objects, which means

             __alloc_object(&obj_pool);

is guaranteed to return an object and cannot return NULL.

So the only reason why this can result in a NULL pointer dereference is
that the obj_to_free list is corrupted. No idea how that should happen.

Maybe some proper reproducer instructions shed some light to it.

Thanks,

        tglx





  reply	other threads:[~2024-09-02  9:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-28 23:27 BUG: general protection fault in __free_object Xingyu Li
2024-09-02  9:21 ` Thomas Gleixner [this message]
2024-09-02 22:55   ` Xingyu Li
2024-09-02 23:22     ` Thomas Gleixner
2024-09-02 23:28       ` Xingyu Li
     [not found] <draft-87y1494nw8.ffs@tglx>
2024-09-03  0:08 ` Thomas Gleixner
2024-09-03  0:10   ` Xingyu Li
2024-09-03  8:58     ` Thomas Gleixner
2024-09-05  5:21       ` Xingyu Li

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=87frqi76ns.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xli399@ucr.edu \
    --cc=yhao016@ucr.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox