linux-kernel - [PATCH V2 net-next 1/2] net: qrtr: Prevent stale ports from sending

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: <20230920053317.2165867-2-quic_srichara@quicinc.com>
Date:   Wed, 20 Sep 2023 11:03:16 +0530
From:   Sricharan Ramabadhran <quic_srichara@...cinc.com>
To:     <mani@...nel.org>, <davem@...emloft.net>, <edumazet@...gle.com>,
        <kuba@...nel.org>, <pabeni@...hat.com>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <netdev@...r.kernel.org>, <quic_viswanat@...cinc.com>,
        <quic_clew@...cinc.com>, <quic_srichara@...cinc.com>,
        <horms@...nel.org>
Subject: [PATCH V2 net-next 1/2] net: qrtr: Prevent stale ports from sending

From: Chris Lew <quic_clew@...cinc.com>

If some client tries to initialize a QRTR socket during QRTR
init, the socket will become stale after the ns(namespace server)
binds to the QRTR control port. The client should close and reopen
the QRTR socket once ENETRESET is posted to the stale socket.

There is a possibility that a client tries to send to the NS before
processing the ENETRESET. In the case of a NEW_SERVER control message,
the control message will reach the NS and be forwarded to the firmware.
The client will then process the ENETRESET closing and re-opening the
socket which triggers a DEL_SERVER and then a second NEW_SERVER.
This scenario will give an unnecessary disconnect to the clients on the
firmware who were able to initialize on the first NEW_SERVER.

This was seen when qrtr-ns was a separate application, but there is
still a potential gap between AF_QIPCRTR socket register and when
qrtr_ns_init binds to the socket where this issue can still occur.

Signed-off-by: Chris Lew <quic_clew@...cinc.com>
Signed-off-by: Vignesh Viswanathan <quic_viswanat@...cinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara@...cinc.com>
---
 [v2]  Added more appropriate commit text,
       Removed a redundant check and fixed local variables
       in reverse-christmas tree order.
       Added 'Chris Lew' Signed-off tag.

 net/qrtr/af_qrtr.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/qrtr/af_qrtr.c b/net/qrtr/af_qrtr.c
index 41ece61eb57a..e5cf4245c3dc 100644
--- a/net/qrtr/af_qrtr.c
+++ b/net/qrtr/af_qrtr.c
@@ -849,6 +849,7 @@ static int qrtr_local_enqueue(struct qrtr_node *node, struct sk_buff *skb,
 			      int type, struct sockaddr_qrtr *from,
 			      struct sockaddr_qrtr *to)
 {
+	struct sock *sk = skb->sk;
 	struct qrtr_sock *ipc;
 	struct qrtr_cb *cb;

@@ -860,6 +861,14 @@ static int qrtr_local_enqueue(struct qrtr_node *node, struct sk_buff *skb,
 		return -ENODEV;
 	}

+	/* Keep resetting NETRESET until socket is closed */
+	if (sk && sk->sk_err == ENETRESET) {
+		sk_error_report(sk);
+		qrtr_port_put(ipc);
+		kfree_skb(skb);
+		return 0;
+	}
+
 	cb = (struct qrtr_cb *)skb->cb;
 	cb->src_node = from->sq_node;
 	cb->src_port = from->sq_port;
-- 
2.34.1