On Fri, Jan 22, 2021 at 06:08:18PM +0900, Vincent MAILHOL wrote: > > > 1. Kernel dump log: > > > [ 101.688327] ------------[ cut here ]------------ [ 101.692968] refcount_t: > > > addition on 0; use-after-free. > > The skb already had its refcount at zero when reaching > can_put_echo_skb(). It is as if it was already freed/consumed! ACK > If you remove Oleksij’s patch, can_put_echo_skb() will probably not > clone the skb and thus not check the refcount: this means that you > will not see the warning, however, it does not necessarily mean that > the bug did not occur. ACK > So far, it seems to me to be another bug which was invisible until > now and which Oleksij’s patch just uncovered. But I do not yet fully > understand what the root cause could be. Or it's the same bug, hitting earlier. Oleksij's backtrace was in the TX-complete path and the problem was fixes by cloning the skb in before TX. This means the refcount of the original skb was decremented between TX and TX-complete. Here the refcount is decremented even before TX. Does this make sense? regareds, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
