linux-kernel - Re: [net v1] net: wwan: t7xx: Fix napi rx poll issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250515175251.58b5123f@kernel.org>
Date: Fri, 16 May 2025 15:30:38 +0800
From: Jinjian Song <jinjian.song@...ocom.com>
To: kuba@...nel.org
Cc: andrew+netdev@...n.ch,
	angelogioacchino.delregno@...labora.com,
	chandrashekar.devegowda@...el.com,
	chiranjeevi.rapolu@...ux.intel.com,
	corbet@....net,
	danielwinkler@...gle.com,
	davem@...emloft.net,
	edumazet@...gle.com,
	haijun.liu@...iatek.com,
	helgaas@...nel.org,
	horms@...nel.org,
	jinjian.song@...ocom.com,
	johannes@...solutions.net,
	linux-arm-kernel@...ts.infradead.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-mediatek@...ts.infradead.org,
	loic.poulain@...aro.org,
	m.chetan.kumar@...ux.intel.com,
	matthias.bgg@...il.com,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	ricardo.martinez@...ux.intel.com,
	ryazanov.s.a@...il.com
Subject: Re: [net v1] net: wwan: t7xx: Fix napi rx poll issue

>On Thu, 15 May 2025 11:17:42 +0800 Jinjian Song wrote:
>> diff --git a/drivers/net/wwan/t7xx/t7xx_netdev.c b/drivers/net/wwan/t7xx/t7xx_netdev.c
>> index 91fa082e9cab..2116ff81728b 100644
>> --- a/drivers/net/wwan/t7xx/t7xx_netdev.c
>> +++ b/drivers/net/wwan/t7xx/t7xx_netdev.c
>> @@ -324,6 +324,7 @@ static void t7xx_ccmni_wwan_dellink(void *ctxt, struct net_device *dev, struct l
>>  	if (WARN_ON(ctlb->ccmni_inst[if_id] != ccmni))
>>  		return;
>>  
>> +	ctlb->ccmni_inst[if_id] = NULL;
>>  	unregister_netdevice(dev);
>
>I don't see any synchronization between this write and NAPI processing.
>Is this safe? NAPI can be at any point of processing as we set the ptr
>to NULL

This panic occured in the scenario where there are frequent disconnect
and connect WWAN cellular on UI.
I debug the panic with gdb and found it as caused by an invalid net_device
during this process:
1.-> t7xx_dpmaif_napi_rx_poll
2.-> t7xx_ccmni_recv_skb 
3.-> napi_gro_receive
4.-> dev_gro_receive
5.-> netif_elide_gro
One way, the net_device using in step 5 is valid, so "dev->features .." panic,
this net_device pass from t7xx_ccmni_recv_skb:
void t7xx_ccmni_recv_skb(...) {
  [...]
  
  ccmni = ccmni_ctlb->ccmni_inst[netif_id];
  if (!ccmni) {
    dev_kfree_skb(skb);
    return;
  }
  
  net_dev = ccmni->dev;
  skb->dev = net_dev;
  [...]
  napi_gro_receive(napi, skb);
  [...]
}

Another way, WWAN disconnect -> wwan_ops.dellink -> t7xx_ccmni_wwan_dellink
-> unregister_netdevice(dev).
netdevice has been invalid, so t7xx_dpmaif_napi_rx_poll can't use it any more.
I mark ccmni_inst[if_id] = NULL with netdevice invalid at the same time.
It seems that a judgment is made every time ccmni_inst[x] is used in the driver,
and the synchronization on the 2 way might have been done when NAPI triggers
polling by napi_schedule and when WWAN trigger dellink. 
So this should be safe.

Jinjian,
Best Regards.