From: Bernd Eckstein <3erndeckstein@xxxxxxxxx> Date: Fri, 23 Nov 2018 13:51:26 +0100 > The bug is not easily reproducable, as it may occur very infrequently > (we had machines with 20minutes heavy downloading before it occurred) > However, on a virual machine (VMWare on Windows 10 host) it occurred > pretty frequently (1-2 seconds after a speedtest was started) > > dev->tx_skb mab be freed via dev_kfree_skb_irq on a callback > before it is set. > > This causes the following problems: > - double free of the skb or potential memory leak > - in dmesg: 'recvmsg bug' and 'recvmsg bug 2' and eventually > general protection fault > > Example dmesg output: ... > The proposed patch eliminates a potential racing condition. > Before, usb_submit_urb was called and _after_ that, the skb was attached > (dev->tx_skb). So, on a callback it was possible, however unlikely that the > skb was freed before it was set. That way (because dev->tx_skb was not set > to NULL after it was freed), it could happen that a skb from a earlier > transmission was freed a second time (and the skb we should have freed did > not get freed at all) > > Now we free the skb directly in ipheth_tx(). It is not passed to the > callback anymore, eliminating the posibility of a double free of the same > skb. Depending on the retval of usb_submit_urb() we use dev_kfree_skb_any() > respectively dev_consume_skb_any() to free the skb. > > Signed-off-by: Oliver Zweigle <Oliver.Zweigle@xxxxxxxx> > Signed-off-by: Bernd Eckstein <3ernd.Eckstein@xxxxxxxxx> Applied and queued up for -stable, thanks.
