From nobody Tue Sep 29 02:04:01 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 64D2247ACF3; Thu, 13 Aug 2026 12:51:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786625510; cv=none; b=UXrMIjH/d9k2JKlQI7EZf6latk1AV25kKUF88LwwoCX1MusG4LY6vnkyyaBhXFGHSvmrnDEnJsHf5STofP+45xd8WUUEx0/XbBZsp2l4wXkW5K9ddLWuGyZK/ugOIQlOrIiEAIIG+WAT4WdTYtZ0mr/bYqNYCJfVgx230LiVTZA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786625510; c=relaxed/simple; bh=Ne7iKpcoXFwoXBKJHi+XN6gSvwmxLP3kwIY8GkMJbLU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=utyEtlmpyh8QGSqf43kMYFpA/GlghUWNEyB9H3Sq7IlYLC76kAtwQZva57ZLGeoBtP2ztRkjqwILJGp3sUiC89tloOxMiMZ0RpNJo91OSuwQ73cwsjiL+emma8Ou5THBg00bZBgIIzcLnR4tkklT045H72zDCo5afwrAt3l8WTk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KYv60lSw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KYv60lSw" Received: by smtp.kernel.org (Postfix) with ESMTPS id BF162C19425; Thu, 13 Aug 2026 12:51:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786625509; bh=Ne7iKpcoXFwoXBKJHi+XN6gSvwmxLP3kwIY8GkMJbLU=; h=From:Date:Subject:To:Cc:Reply-To:From; b=KYv60lSwcFqhNByzrikct2RD2nws4+NKumIBkxA3id/DJo/56UwtgLZ0ra2TZaYzg QbFJ2YJxGeYQdf2Kycs8PLx/uE01EbXX1fdYSMXzxJ/rAssQSBQc143qWD+ZMnAz0w 2C0tc4sWy5oYue0puKfYdgkSlH5bd9JrN8hsb3j+p9JTPln6FGyzppJfCaEhVCE5rt 4kngcUVLi50+vQb5EhT66lS61dZi8msoree80CT0TokDHtBcExflfQew/3BG7mWz+V 8UMk0hnJMm0UXxPBjJJ4ZqUlLCU/QsoXLm8AGviBruYg+6AAwBD3O345wt/kcYY9ak NDBsSUAbyTvWg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id A44B3C5B572; Thu, 13 Aug 2026 12:51:49 +0000 (UTC) From: Bryam Vargas via B4 Relay Date: Thu, 13 Aug 2026 07:51:48 -0500 Subject: [PATCH net] net/iucv: only deliver HiperSockets frames to HiperSockets sockets Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260813-b4-disp-60433a46-v1-1-509e1200533e@proton.me> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/yWMywqDMBAAf0X23IW8SKu/UjzEZG23hyhZFUH8d 9P2OAMzBwgVJoGuOaDQxsJTrqBvDcR3yC9CTpXBKOPVQ1scHCaWGb1y1gbncYwpBt3etWkD1Gw uNPL+Wz4h0wL9X8o6fCgu3xmc5wWnTC1ZeQAAAA== X-Change-ID: 20260813-b4-disp-60433a46-fcdca197129a To: Alexandra Winter , "David S. Miller" , Paolo Abeni , Jakub Kicinski , Eric Dumazet , Thorsten Winkler Cc: linux-s390@vger.kernel.org, Hidayath Khan , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org X-Mailer: b4 0.15.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1786625507; l=3707; i=hexlabsecurity@proton.me; s=default; h=from:subject:message-id; bh=nDOO3oM08heQVmzsx4LEcCLvEFOxohiC/gWc4G5L6Gg=; b=l2IbGlWnwmg8daONne+d5f+6rWwtJIyBaGnEXDj6isxGgubMLGKKusZP3Tu/SQsv/71jDIYu+ BfZJ0aGAI9yA4d8vJMu9Wm+iKi5w6rqiRhgihiDKe17glQBlkjbU+wI X-Developer-Key: i=hexlabsecurity@proton.me; a=ed25519; pk=xw1AhCtQdvuoQc+bOQIYy9o8G++cp4/VniI2G/tc3G8= X-Endpoint-Received: by B4 Relay for hexlabsecurity@proton.me/default with auth_id=893 X-Original-From: Bryam Vargas Reply-To: hexlabsecurity@proton.me From: Bryam Vargas afiucv_hs_rcv() selects a socket out of iucv_sk_list by the four name fields alone, with no test on iucv->transport, so a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport. iucv_sock_bind() makes that reachable rather than theoretical: a bind to the local guest userid always takes the classic path, even on a guest that also carries a HiperSockets device with the same identifier. Skip sockets that are not on the HiperSockets transport. The two were added as alternatives for environments assumed disjoint - IUCV under z/VM, HiperSockets on LPAR - and this lookup still assumes a guest has only one of them. Fixes: 3881ac441f64 ("af_iucv: add HiperSockets transport") Signed-off-by: Bryam Vargas Reviewed-by: Alexandra Winter --- The two transports were introduced as alternatives for environments the 2011 series treated as disjoint. Its cover letter says so: "The current transport mechanism for af_iucv (iucv) is only available on VM. HiperSockets provide similar capabilities as iucv and are available on LPAR." https://lore.kernel.org/all/20110727161339.530894848@de.ibm.com/ That premise is the one to check, and it is yours to settle: on a z/VM guest that also has a HiperSockets device both exist at once, and iucv_sock_bind() resolves the local userid to the classic transport at the test against iucv_userid. If a guest can never reach both, this patch is unnecessary and I would rather know that than have it applied. Reach is wider than the HiperSockets LAN, which is what decides how urgently this is worth taking: iucv_packet_type sets no .dev, afiucv_hs_rcv() ignores its dev argument, and nothing checks dev_net() -- net/x25/x25_dev.c and net/ieee802154/socket.c both do at exactly that point. An AF_PACKET frame on lo from any netns holding CAP_NET_RAW reaches these sockets. Two consequences I traced on a classic socket that matches an inbound frame: afiucv_hs_callback_synfin() and _fin() overwrite its sk_state, and afiucv_hs_callback_syn() builds an accept-queue child with transport HIPER but hs_dev NULL, which LL_RESERVED_SPACE() dereferences unguarded on the first send. That read lands in mapped lowcore on a default kernel and afiucv_hs_send() then returns -ENODEV, so I am not claiming a panic; it faults with relocate_lowcore. By inspection; not reproduced. Compile-tested for s390x. One case where this patch is a regression: a device whose hsuid is set to the same 8 characters as the guest's z/VM userid. iucv_sock_bind() tests siucv_user_id against iucv_userid before it scans for a HiperSockets device, so such a socket becomes classic and today receives HiperSockets frames only because this lookup does not filter. After this patch it stops receiving them. If that configuration is one you support, then this is the wrong patch and the fix belongs in the bind ordering. --- net/iucv/af_iucv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c index ea047bab65e7..5fb6793b9a64 100644 --- a/net/iucv/af_iucv.c +++ b/net/iucv/af_iucv.c @@ -2079,6 +2079,8 @@ static int afiucv_hs_rcv(struct sk_buff *skb, struct = net_device *dev, sk =3D NULL; read_lock(&iucv_sk_list.lock); sk_for_each(sk, &iucv_sk_list.head) { + if (iucv_sk(sk)->transport !=3D AF_IUCV_TRANS_HIPER) + continue; if (trans_hdr->flags =3D=3D AF_IUCV_FLAG_SYN) { if ((!memcmp(&iucv_sk(sk)->src_name, trans_hdr->destAppName, 8)) && --- base-commit: 9006c116dd111d457bf5d074990210f70a4ad2c8 change-id: 20260813-b4-disp-60433a46-fcdca197129a Best regards, -- =20 Bryam Vargas