From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A68A93E9C3E for ; Fri, 15 May 2026 20:45:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778877931; cv=none; b=AP/Uc81o0A9MZuU/H8V79xenoZRGKP1RtJUBzKZsZF8UqfP3eAHtWWDK3P1gpge6BQOJmAWbQJDz01sdLlRKpB4D8nC+SI8PK/BTCVjtKk8JD4ZyAANYvW9DCPbF3L6s4CqlfYI6g2dHwVQW0UuogrmH67xh2Wa1DJJS9cAYwt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778877931; c=relaxed/simple; bh=jYFCW0q2oH14t/Tdq68TImEf4QAJ0L7oEU4dKSkZpjY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UwQkVpktDjBYaaSlbHgvF45iG+Ld5lmyfy9SSFxmma3rWxRxpv122B+tIyijZUM9fW3+n5LI9B+y8H4Xh5TshvEPdr/TUg2QXAguppv5QiS9fs38Prq/2NgwZZvgOEHNCH/mwK037Xp31Qtn33syTAxBnMivgq+vOzBtNyYRbag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=F/DPFY2q; arc=none smtp.client-ip=209.85.216.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F/DPFY2q" Received: by mail-pj1-f67.google.com with SMTP id 98e67ed59e1d1-3665b67ed66so122827a91.1 for ; Fri, 15 May 2026 13:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778877929; x=1779482729; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5Jp3G/+8nHauE/XI0omIm5SsO4BbcTyQ1cU6IXSGwNU=; b=F/DPFY2qHcEADU66AoQ/HAiAUlJsUgix7K5w2KL/d345RfzWcZ6/PEzo+Y1thEIbVX D6pBggvaMQ4CeZvz4e+7UIecvaw/fDIZTZOkyf4rTCXp8iRSySBbW5Vno5f6XClfLy7Y sscb1UyDNZCvN4XOc4pZdW+IpC1S9opSJKuKSfZtVKazLuGgEpBJ2rL4274QDUb86avo elS6sVawMNeL20eBSkLQWSVJPwOQOeKdunhYEgARNhF1tAB1DyIDQv4PWfB89guc5O5g gcEfpJiN7Fy5RO8kI6D5jH+ss5UEHZ/1xjMKWg0S9lcPhQKlHmRuYKtZ37PYOKKX6rjq EE3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778877929; x=1779482729; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5Jp3G/+8nHauE/XI0omIm5SsO4BbcTyQ1cU6IXSGwNU=; b=qdecMNeWZEK3wLvAUVMWkawByWNCxRKW9CNdh0HFgNH2eZzkEb190V6etgrnCb+Je+ MQPXYW9qf1lAWkObe8CD/ZoT4lJxoHl0IkHB7tlGe8IUTaHBZ29/4IG//G2vUbjsmnD3 QWm7QxH59bt44OC1ABouE71zo76W2eWhGoUu3S8977MRKoB9QZJaib0tpuj0jtlqAyN4 AmvbTT8cwbv6ufG96bN/gmUXJJEwwGx6scey2r/uykFPyugKfhuE6swaEDdU/AkooHz2 rg6z/o+qhZDBhS+XkZckfbW8OfMoTMcVna0KCWgxPMrkjmaTsw9VV9iCEuEn0D+IP8F/ iZew== X-Forwarded-Encrypted: i=1; AFNElJ/4PqmChJhLQur8/BXRxR9f1GIZvQpYoljLjqB5342YbSBJWoWjPVkRki9byhhWkSTwHYePY0MrD/Twauo=@vger.kernel.org X-Gm-Message-State: AOJu0YwxUPcHEqB2HMVmc7dtWqiaur0K6ljyhWspY0ub7gRsbFVffzS4 d2cLPA+j33ddjRsWvyZSI6eU8DS4ASKA4bPNxWlyCyelT0WNA/YVVg0V X-Gm-Gg: Acq92OGQ7tHqhVpDtxZ7ozeK0NiiS5VCGlUJXDOYjfgU5T6bJ0Nf48+37cJg4u/9yDW nkh7JTOLm6iQbriU5fk/UnEWwqNTIFpXIJOAlzv+5CTgIRKPXaehRGi9GsnAL/nDwcfQgFH2gbH j8+0Pco9nmgo92pJ+g4nO2k+pEBUCS6T7QZP7kh9nVLXY2dndU9H7ioDxk8df/ND+jyYO3+aphz RqwaA2iUe/7mbhmSmVZa1VIlXm7NfoOPk17FwuJEwRi06fv53ZaamQFMNPC29+/qzoVuoXGZnQp T9kJaPXo7Nnr3qYoaKQQXevkPHQ+4Ii0u6lUwom0WkXCBnM/vT2ZWNXbgJG73jMPNSO/gAzffx3 p2c8q9NWVeDnHZ9mo+J893mUxKmM1GB3wD292+7tH6cL8gBTTlDwBuwV8zxEkonUX3AITIA9F2U jJ6CGSfLFbI7FtVi4j X-Received: by 2002:a17:90b:1810:b0:35c:cba:3453 with SMTP id 98e67ed59e1d1-36951ca602amr5899046a91.22.1778877928785; Fri, 15 May 2026 13:45:28 -0700 (PDT) Received: from localhost ([2a03:2880:2ff:5f::]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-369703bcc91sm167683a91.3.2026.05.15.13.45.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 13:45:28 -0700 (PDT) Date: Fri, 15 May 2026 13:45:27 -0700 From: Stanislav Fomichev To: Breno Leitao Cc: Chas Williams <3chas3@gmail.com>, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Magnus Karlsson , Maciej Fijalkowski , Stanislav Fomichev , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Jon Maloy , Alexandra Winter , Thorsten Winkler , James Chapman , David Howells , Marc Dionne , David Heidelberg , Samuel Ortiz , linux-atm-general@lists.sourceforge.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, tipc-discussion@lists.sourceforge.net, linux-s390@vger.kernel.org, linux-afs@lists.infradead.org, oe-linux-nfc@lists.linux.dev, kernel-team@meta.com Subject: Re: [PATCH net-next v2 1/7] af_iucv: take socket lock around SO_MSGSIZE getsockopt Message-ID: References: <20260515-getsock_four-v2-0-0d8eed952627@debian.org> <20260515-getsock_four-v2-1-0d8eed952627@debian.org> 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-Disposition: inline In-Reply-To: <20260515-getsock_four-v2-1-0d8eed952627@debian.org> On 05/15, Breno Leitao wrote: > Mirror the locking used by the SO_MSGLIMIT case directly above: take > lock_sock() before reading iucv->hs_dev and dereferencing hs_dev->mtu, > and release it afterwards. This keeps the two adjacent getsockopt arms > consistent and matches the lock held by iucv_sock_close() when it > clears hs_dev. > > This is not an exploitable bug. iucv_sock_close() is the only writer > of iucv->hs_dev and only runs from the protocol release callback, > which the socket layer invokes after the last file reference drops. > The getsockopt() syscall holds an fd reference for its entire > duration via fdget()/fdput(), so iucv_sock_close() cannot run > concurrently with the SO_MSGSIZE read on the same socket. There is > no other writer of hs_dev, and the aligned pointer load cannot tear > on any architecture Linux supports, so the existing code cannot > observe a NULL dereference or use-after-free in practice. > > The change is purely defensive: making the locking pattern uniform > across the function avoids surprising the next reader and removes a > foot-gun should the close path ever grow a new caller that does not > hold the fd reference. > > Note: For the reason above, it doesn't contain a "Fixes" tag, and is > aiming at net-next instead of net. > > Signed-off-by: Breno Leitao > --- > 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 72dfccd4e3d58..3dd11d7a967c8 100644 > --- a/net/iucv/af_iucv.c > +++ b/net/iucv/af_iucv.c > @@ -1566,9 +1566,11 @@ static int iucv_sock_getsockopt(struct socket *sock, int level, int optname, > case SO_MSGSIZE: > if (sk->sk_state == IUCV_OPEN) > return -EBADFD; > + lock_sock(sk); > val = (iucv->hs_dev) ? iucv->hs_dev->mtu - > sizeof(struct af_iucv_trans_hdr) - ETH_HLEN : > 0x7fffffff; > + release_sock(sk); > break; > default: > return -ENOPROTOOPT; > SO_IPRMDATA_MSG also seems to be only reading the value set via setsockopt, so maybe it's ok to just cover the whole switch with lock/unlock? (will mirror what setsockopt does)