[PATCH] net: qrtr: Reintroduce ARCH_QCOM as a dependency for QRTR

[PATCH] net: qrtr: Reintroduce ARCH_QCOM as a dependency for QRTR

[Anant Thazhemadam]

Removing ARCH_QCOM, as a dependency for QRTR begins to give rise to
issues with respect to maintaining reference count integrity and
suspicious rcu usage.

The bugs resolved by making QRTR dependent on ARCH_QCOM include:

* WARNING: refcount bug in qrtr_node_lookup
Reported-by: syzbot+c613e88b3093ebf3686e@syzkaller.appspotmail.com
* WARNING: refcount bug in qrtr_recvmsg
Reported-by: syzbot+d0f27d9af17914bf253b@syzkaller.appspotmail.com
* WARNING: suspicious RCU usage in ctrl_cmd_new_lookup
Reported-by: syzbot+3025b9294f8cb0ede850@syzkaller.appspotmail.com
* WARNING: suspicious RCU usage in qrtr_ns_worker
Reported-by: syzbot+0f84f6eed90503da72fc@syzkaller.appspotmail.com

Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
---
As I understand it, QRTR was initially dependent upon ARCH_QCOM, but was 
removed since not all modems using IPC Router protocol required the 
support provided for Qualcomm platforms. 
However, wouldn't ARCH_QCOM be required by the modems that require the 
support provided for Qualcomm platforms?
The configuration ARCH_QCOM isn't exactly the easiest to find, especially, 
for those who don't know what they're looking for (syzbot included, I 
guess).
I don't feel like the tradeoff of not depending on ARCH_QCOM over giving 
rise to potential bugs is worth it. 
Is NOT having QRTR depend on ARCH_QCOM so critical that it supersedes the 
priority of not giving rise to potential bugs?

 net/qrtr/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
index b4020b84760f..8156d0f3656b 100644
--- a/net/qrtr/Kconfig
+++ b/net/qrtr/Kconfig
@@ -4,6 +4,7 @@
 
 config QRTR
 	tristate "Qualcomm IPC Router support"
+	depends on ARCH_QCOM
 	help
 	  Say Y if you intend to use Qualcomm IPC router protocol.  The
 	  protocol is used to communicate with services provided by other
-- 
2.25.1

Re: [PATCH] net: qrtr: Reintroduce ARCH_QCOM as a dependency for QRTR

[Anant Thazhemadam]

On 09/09/20 5:03 am, Anant Thazhemadam wrote:
> Removing ARCH_QCOM, as a dependency for QRTR begins to give rise to
> issues with respect to maintaining reference count integrity and
> suspicious rcu usage.
>
> The bugs resolved by making QRTR dependent on ARCH_QCOM include:
>
> * WARNING: refcount bug in qrtr_node_lookup
> Reported-by: syzbot+c613e88b3093ebf3686e@syzkaller.appspotmail.com
> * WARNING: refcount bug in qrtr_recvmsg
> Reported-by: syzbot+d0f27d9af17914bf253b@syzkaller.appspotmail.com
> * WARNING: suspicious RCU usage in ctrl_cmd_new_lookup
> Reported-by: syzbot+3025b9294f8cb0ede850@syzkaller.appspotmail.com
> * WARNING: suspicious RCU usage in qrtr_ns_worker
> Reported-by: syzbot+0f84f6eed90503da72fc@syzkaller.appspotmail.com
>
> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
> ---
> As I understand it, QRTR was initially dependent upon ARCH_QCOM, but was 
> removed since not all modems using IPC Router protocol required the 
> support provided for Qualcomm platforms. 
> However, wouldn't ARCH_QCOM be required by the modems that require the 
> support provided for Qualcomm platforms?
> The configuration ARCH_QCOM isn't exactly the easiest to find, especially, 
> for those who don't know what they're looking for (syzbot included, I 
> guess).
> I don't feel like the tradeoff of not depending on ARCH_QCOM over giving 
> rise to potential bugs is worth it. 
> Is NOT having QRTR depend on ARCH_QCOM so critical that it supersedes the 
> priority of not giving rise to potential bugs?
>
>  net/qrtr/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
> index b4020b84760f..8156d0f3656b 100644
> --- a/net/qrtr/Kconfig
> +++ b/net/qrtr/Kconfig
> @@ -4,6 +4,7 @@
>  
>  config QRTR
>  	tristate "Qualcomm IPC Router support"
> +	depends on ARCH_QCOM
>  	help
>  	  Say Y if you intend to use Qualcomm IPC router protocol.  The
>  	  protocol is used to communicate with services provided by other
I believe I've been mistaken. I realize, requiring ARCH_QCOM wouldn't
extend functionality, but would limit it to ONLY Qualcomm platforms.
That makes sense, and would also explain the false positive results
obtained when tried to test with syzbot, since syzbot wouldn't be
able to build in the first place.

Sorry for the trouble, you may ignore this patch.

thanks,
Anant