From: Vlastimil Babka <vbabka@suse.cz>
To: Thibaut Sautereau <thibaut.sautereau@clip-os.org>,
netdev@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
Laura Abbott <labbott@redhat.com>,
Kees Cook <keescook@chromium.org>,
Alexander Potapenko <glider@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
clipos@ssi.gouv.fr
Subject: Re: Double free of struct sk_buff reported by SLAB_CONSISTENCY_CHECKS with init_on_free
Date: Tue, 5 Nov 2019 10:00:39 +0100 [thread overview]
Message-ID: <23c73a23-8fd9-c462-902b-eec2a0c04d36@suse.cz> (raw)
In-Reply-To: <20191104170303.GA50361@gandi.net>
On 11/4/19 6:03 PM, Thibaut Sautereau wrote:
> The BUG only happens when using `slub_debug=F` on the command-line (to
> enable SLAB_CONSISTENCY_CHECKS), otherwise the double free is not
> reported and the system keeps running.
You could change slub_debug parameter to:
slub_debug=FU,skbuff_head_cache
That will also print out who previously allocated and freed the double
freed object. And limit all the tracking just to the affected cache.
> The code path is:
> net_rx_action
> __kfree_skb_flush
> kmem_cache_free_bulk() # skbuff_head_cache
> slab_free()
> do_slab_free()
> __slab_free()
> free_debug_processing()
> free_consistency_check()
> object_err() # "Object already free"
> print_trailer()
> print_tracking() # !(s->flags & SLAB_STORE_USER) => return;
> print_page_info() # "INFO: Slab ..."
> pr_err("INFO: Object ...", ..., get_freepointer(s, p))
> get_freepointer()
> freelist_dereference() # NULL pointer dereference
>
> Enabling KASAN shows less info because the NULL pointer dereference then
> apparently happens before reaching free_debug_processing().
>
> Bisection points to the following commit: 1b7e816fc80e ("mm: slub: Fix
> slab walking for init_on_free"), and indeed the BUG is not triggered
> when init_on_free is disabled.
That could be either buggy SLUB code, or the commit somehow exposed a
real bug in skbuff users.
next prev parent reply other threads:[~2019-11-05 9:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 17:03 Double free of struct sk_buff reported by SLAB_CONSISTENCY_CHECKS with init_on_free Thibaut Sautereau
2019-11-04 17:33 ` Eric Dumazet
2019-11-05 8:05 ` Thibaut Sautereau
2019-11-05 10:19 ` Alexander Potapenko
2019-11-05 15:04 ` Thibaut Sautereau
2019-11-05 9:00 ` Vlastimil Babka [this message]
2019-11-05 14:32 ` Thibaut Sautereau
2019-11-05 15:02 ` Vlastimil Babka
2019-11-05 17:01 ` Laura Abbott
2019-11-06 9:29 ` Thibaut Sautereau
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=23c73a23-8fd9-c462-902b-eec2a0c04d36@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=clipos@ssi.gouv.fr \
--cc=davem@davemloft.net \
--cc=glider@google.com \
--cc=keescook@chromium.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=thibaut.sautereau@clip-os.org \
/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;
as well as URLs for NNTP newsgroup(s).