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.
