[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <23c73a23-8fd9-c462-902b-eec2a0c04d36@suse.cz>
Date: Tue, 5 Nov 2019 10:00:39 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Thibaut Sautereau <thibaut.sautereau@...p-os.org>,
netdev@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
Laura Abbott <labbott@...hat.com>,
Kees Cook <keescook@...omium.org>,
Alexander Potapenko <glider@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>, clipos@....gouv.fr
Subject: Re: Double free of struct sk_buff reported by SLAB_CONSISTENCY_CHECKS
with init_on_free
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.
Powered by blists - more mailing lists