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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed,  9 Sep 2020 05:03:28 +0530
From:   Anant Thazhemadam <anant.thazhemadam@...il.com>
To:     unlisted-recipients:; (no To-header on input)
Cc:     linux-kernel-mentees@...ts.linuxfoundation.org,
        Anant Thazhemadam <anant.thazhemadam@...il.com>,
        syzbot+c613e88b3093ebf3686e@...kaller.appspotmail.com,
        syzbot+d0f27d9af17914bf253b@...kaller.appspotmail.com,
        syzbot+3025b9294f8cb0ede850@...kaller.appspotmail.com,
        syzbot+0f84f6eed90503da72fc@...kaller.appspotmail.com,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Masahiro Yamada <masahiroy@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH] net: qrtr: Reintroduce ARCH_QCOM as a dependency for QRTR

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@...kaller.appspotmail.com
* WARNING: refcount bug in qrtr_recvmsg
Reported-by: syzbot+d0f27d9af17914bf253b@...kaller.appspotmail.com
* WARNING: suspicious RCU usage in ctrl_cmd_new_lookup
Reported-by: syzbot+3025b9294f8cb0ede850@...kaller.appspotmail.com
* WARNING: suspicious RCU usage in qrtr_ns_worker
Reported-by: syzbot+0f84f6eed90503da72fc@...kaller.appspotmail.com

Signed-off-by: Anant Thazhemadam <anant.thazhemadam@...il.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

Powered by blists - more mailing lists