From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=109.224.244.17 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793247497; b=bYdHvL8dq/3G/BI2QUua6XY5qljlaHdNMH5AlFzWojvppJ5tKU6MYmx9Nu1TVmWSnyXE XUS7g1FH7dmBbXBxoajUtyNGXqzJyurT2MPw6/ljxt/AZIBBLwrnSVMdVpwV97sGrzO1h eAAETPsVZO1MCf6ZGEi/qunMPsMlsySzHzRLluKTEYSVxrCLl5IkMKBT1orUHTw/UQ5iW 2o9BEExPn9QgHDqTqA4HAi+uF0HHN5E1WxG3lI0hLOqMyfpZCte4L5YRmRU392i+nsET2 gml81tD03K+NwkMd0Gp+FFLNUuQX79m+HYzvy05jSjWLXs9h3CFdDclKDR3Pry7BXIQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793247497; h=DMARC-Filter:DKIM-Signature:Date:To:From:Cc:Subject:Message-ID: In-Reply-To:References:Feedback-ID:X-Pm-Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=4V1QY5rnLtUFHVy7j/lGfFmVKAOrcLlyIp4tAu9on10=; b=WCY31Bgx+gpowcr6sujUkMrkDQ78qd9hw2m9LQgB5QYFdvUiPkvHQ806KF3MMNoO1+m4 86gc3POGEAG2AIwowt45jDJnirJMzrsDJcOA1nzYxWkxbVeltXVS+sjUIDvCsfUftgxe7 9UpQ7Cs6CMfWTBA5S2wxEtgjZWB8GCe/AHyibmGztT0gK1GmezvXMK1SZurD92c0LJBrz 3u4xCbo5w9tzfYRQi2zUNZfjmlor4jh6TgdAxQ8qEwfKILAKLYqOaBkne3S8JmHB6jASg vjltUGfJ8P5rngf0i0TdjOkcyINBroQ5+kSa0l11j9fsDgECgWUp5xVpzTXxCuVtiJQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass header.d=proton.me header.i=@proton.me header.a=rsa-sha256 header.s=protonmail2 header.b=fHRp8W2g; arc=none smtp.remote-ip=109.224.244.17 Received: from mail-24417.protonmail.ch (mail-24417.protonmail.ch [109.224.244.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE8EB606A31A for ; Thu, 29 Oct 2026 04:18:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org AE8EB606A31A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=proton.me header.i=@proton.me header.a=rsa-sha256 header.s=protonmail2 header.b=fHRp8W2g DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail2; t=1793247494; x=1793506694; bh=4V1QY5rnLtUFHVy7j/lGfFmVKAOrcLlyIp4tAu9on10=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fHRp8W2gJD0gY0Fo5rTfRNWS7qxDo2ppPVVSc62ChZObnOe3b5vwCQy/NOsQtYEWq VHDNQU/8RS70HsOooNpvhfSuLjwQ+sfzz4i31Drzp4/2PRtfPCLFaOLesJfh7fg4gV FISGAtcmL05utbMMn7IecyJupEJrit2550Fl9sg7nTRbcLRMnopbY9xHmqZ67D0e9H llpk1REyDaMdis86iAo2aN05NVwmmGVhQcmrIEUZny0M4STGdQea+4CcOXpaEJUopm PJVq4bndCvif/YfDDMNj/R8Wzm48jIvOtsc07sW6IcDYX0bdLdDioOQ/GVS8SZE6Ce Mkhih7RqKvEZg== Date: Thu, 29 Oct 2026 04:18:08 +0000 To: netdev-bot+sashiko@kernel.org, Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S . Miller" , Alexandra Winter , Thorsten Winkler From: Bryam Vargas Cc: Simon Horman , Hidayath Khan , Nagamani PV , linux-s390@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net 2/2] net/iucv: do not count the SHT frame against the receive window Message-ID: <20261029041801.406712-1-hexlabsecurity@proton.me> In-Reply-To: <179306942509.3134.1109951482403010755@kernel.org> References: <20261022-b4-disp-b35a9153-v1-2-d74645876195@proton.me> <179306942509.3134.1109951482403010755@kernel.org> Feedback-ID: 199661219:user:proton X-Pm-Message-ID: 18184e39b0757656a9ad30fcbcf0ef6c97309a0d X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 27 Oct 2026 02:50:25 +0000, netdev-bot+sashiko@kernel.org wrote: > [Severity: High] > Can an empty frame read after the over-window close reach > iucv_send_ctrl() while iucv->hs_dev is NULL? Yes. The close purges backlog_skb_q, not sk_receive_queue, msg_recv stays over the limit, and with the length test an empty frame read after it skips the -EFAULT branch and lands in the window update. Repro on the emulated s390x setup with SO_MSGLIMIT 2: the peer sends twice (the window), then from a tap on its interface one data frame over the window, its SHUT_WR for the SHT, and 16 more data frames behind it, so backlog_skb_q is not empty and no read sends a window update before the close (a Linux peer blocks at the window; the overrun is injected). Six reads: 1, 1, -EFAULT (the close), -ECONNRESET, 0 (the SHT), -EFAULT (a data frame behind the SHT closes again). On v1 the fifth read enters iucv_send_ctrl() once, with nothing leaving the adapter. The reads are the same with and without the bug: on a default boot the NULL read lands in the lowcore and afiucv_hs_send() fails with -ENODEV, as you say, so nothing shows from user space. v2 sends the update only while the socket is connected; the same run then shows no attempt after the close. > [Severity: Medium] > This is a pre-existing issue, but does a zero-length data frame always > arrive at the receiver as an empty data frame? No. With a credit piggybacked it is a window update to afiucv_hs_rcv() and never reaches recvmsg(). v2 narrows the sentence to "a zero-length data frame that reaches recvmsg()". The slot the sender loses there is the tx side's own accounting, not this patch's. > [Severity: Medium] > This is a pre-existing issue, but the classic IUCV transport still has a > WARN that a peer can trigger, of the same kind as the one removed here. Same kind, agreed, and iucv_process_message_q() retries the oversize message on every read. That is the z/VM transport, not this path; out of scope here. > [Severity: High] > This isn't a bug introduced by this patch, but this read-time check is > the only window enforcement on the receive side. Can a peer that ignores > its window grow iucv->backlog_skb_q without limit? Today it can: nothing on arrival counts against the window, and backlog_skb_q is neither bounded nor charged. This patch takes a WARN off that check and does not move the enforcement; the bound belongs on the rx side at arrival and is not this patch's. > [Severity: Medium] > This is a pre-existing issue, but can a conforming peer still reach this > close? Yes, by lowering SO_MSGLIMIT in IUCV_BOUND below the window the SYN advertised; that is the case in the notes below the patch. Not in the commit message or the comment: 2/2 only stops counting the SHT and takes the WARN off, and the socket enforcing a window other than the one it advertised is the series' fix. The locking series keeps the advertised window in its own field, so the budget, this check and the update threshold read the same number. > [Severity: Low] > Two unsynchronized writes to sk->sk_shutdown can lose RCV_SHUTDOWN. Pre-existing; the series puts both writes under the same lock. Thanks, Bryam pw-bot: cr