dp83640: don't recieve time stamps twice

Submitted by Dan Carpenter on April 18, 2017, 7:14 p.m.

Details

Message ID 20170418191426.GA17838@mwanda
State Accepted
Delegated to: David Miller
Headers show

Commit Message

Dan Carpenter April 18, 2017, 7:14 p.m.
This patch is prompted by a static checker warning about a potential
use after free.  The concern is that netif_rx_ni() can free "skb" and we
call it twice.

When I look at the commit that added this, it looks like some stray
lines were added accidentally.  It doesn't make sense to me that we
would recieve the same data two times.  I asked the author but never
recieved a response.

I can't test this code, but I'm pretty sure my patch is correct.

Fixes: 4b063258ab93 ("dp83640: Delay scheduled work.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

Comments

Richard Cochran April 18, 2017, 8:19 p.m.
On Tue, Apr 18, 2017 at 10:14:26PM +0300, Dan Carpenter wrote:
> This patch is prompted by a static checker warning about a potential
> use after free.  The concern is that netif_rx_ni() can free "skb" and we
> call it twice.

Right, the code already calls netif_rx_ni() in the list_for_each_safe()
loop just above, in the case that the shhwtstamps pointer has been set.
 
> When I look at the commit that added this, it looks like some stray
> lines were added accidentally.  It doesn't make sense to me that we
> would recieve the same data two times.  I asked the author but never
> recieved a response.

Hm, maybe the intent was to move the call to netif_rx_ni() outside of
the spin_lock_irqsave() region (which how I had it before Stefan's
changes).

But calling netif_rx_ni() twice is clearly wrong.

Thanks,
Richard
Stefan Sørensen April 19, 2017, 9:16 a.m.
On Tue, 2017-04-18 at 22:14 +0300, Dan Carpenter wrote:
> This patch is prompted by a static checker warning about a potential

> use after free.  The concern is that netif_rx_ni() can free "skb" and

> we

> call it twice.

> 

> When I look at the commit that added this, it looks like some stray

> lines were added accidentally.  It doesn't make sense to me that we

> would recieve the same data two times.  I asked the author but never

> recieved a response.

> 

> I can't test this code, but I'm pretty sure my patch is correct.


Sorry for not getting back earlier, I have swamped with other stuff.

You are correct that these lines was added accidentally.

Acked-by: Stefan Sørensen <stefan.sorensen@spectralink.com>


> 

> Fixes: 4b063258ab93 ("dp83640: Delay scheduled work.")

> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

> 

> diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c

> index e2460a57e4b1..ed0d10f54f26 100644

> --- a/drivers/net/phy/dp83640.c

> +++ b/drivers/net/phy/dp83640.c

> @@ -1438,8 +1438,6 @@ static bool dp83640_rxtstamp(struct phy_device

> *phydev,

>  		skb_info->tmo = jiffies + SKB_TIMESTAMP_TIMEOUT;

>  		skb_queue_tail(&dp83640->rx_queue, skb);

>  		schedule_delayed_work(&dp83640->ts_work,

> SKB_TIMESTAMP_TIMEOUT);

> -	} else {

> -		netif_rx_ni(skb);

>  	}

>  

>  	return true;

Patch hide | download patch | download mbox

diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index e2460a57e4b1..ed0d10f54f26 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -1438,8 +1438,6 @@  static bool dp83640_rxtstamp(struct phy_device *phydev,
 		skb_info->tmo = jiffies + SKB_TIMESTAMP_TIMEOUT;
 		skb_queue_tail(&dp83640->rx_queue, skb);
 		schedule_delayed_work(&dp83640->ts_work, SKB_TIMESTAMP_TIMEOUT);
-	} else {
-		netif_rx_ni(skb);
 	}
 
 	return true;