netdev - Re: [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: <kzl2n3jo4x4eicfnorm7ozxvyzyrrhjgvnqir52uxovo5wp5n7@xtvecqtxepyl>
Date: Wed, 20 Sep 2023 05:48:09 -0700
From: Bjorn Andersson <andersson@...nel.org>
To: Sricharan Ramabadhran <quic_srichara@...cinc.com>
Cc: 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, horms@...nel.org
Subject: Re: [PATCH V2 net-next 1/2] net: qrtr: Prevent stale ports from
 sending

On Wed, Sep 20, 2023 at 11:03:16AM +0530, Sricharan Ramabadhran wrote:
> 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>

Reviewed-by: Bjorn Andersson <andersson@...nel.org>

Regards,
Bjorn