From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (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 0A3F9386555 for ; Tue, 12 May 2026 21:36:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778621775; cv=none; b=FFbDEx+q3aBvCRBExrsOm7+v8+zZNc1tXNoDn6gHM9f9OOR8Y9qM8BsrHlszS121UWxCEaFqIrfUitpzXvZXgY2dh7kHW4EG27RV/YGg006FjnVUyWPpokxpH/fplaC/1V1gHbN0Evj3u6K6OkjjKcRpwBboefi7Cz1XUyN1p+o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778621775; c=relaxed/simple; bh=2CAQv7WlIuAn9ZzlbSWxK35EKEEcUTbGAVGhewVtMtY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mQHeKYoS8Q+LCUwUdcwm/+KYtb+ou04dgCxY3tBMI2YOtxIZK/oT4jedf5eRfvsD9ixpwLeeK9xVlt4rBf6C4GGXWPomP1FAjUkb412SYpnnvNDyav3DeIStHMWgiqryuaxjVkuaeNdAosO0q7dimvbkCzbZfvQG2Xo4mg/JQEk= 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=Man6gt3H; arc=none smtp.client-ip=209.85.218.44 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="Man6gt3H" Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-b79f8f7ea43so934645466b.2 for ; Tue, 12 May 2026 14:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778621772; x=1779226572; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=7AjtpQdf3BmRecSAJyeyKfM2fj5WACdiXZCkmVYfRjk=; b=Man6gt3HqG6GzEP1vSuEzftvOuWnSv16zXSzP6qL11GKFd3TdlLJNaShwgFMqswMKg D0omN2+Owj3Emb0iUoEl5E1kDgRVS5p2LqJQaoZSipbppgpw2HBV7tbx6FLO8xoTk5iQ H0980Js9f9AE79xQ3aflnZmkUHMZvvx7VjsPhwS+Qfm2HGII7k3ohC5O+GVrHh0plJZj JshrsjIkJ6mVts+YXQIpBifTVayW8ub4hE7W50ut0Zio4BnS4OI5JCBzGACH6mh8o4xR wByQ4/tiiPbf2TtofEsLljXmgO7DeDqNnAkNpQpNNZplV+hLn/FyMht1i453aCvnBnM1 8MbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778621772; x=1779226572; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7AjtpQdf3BmRecSAJyeyKfM2fj5WACdiXZCkmVYfRjk=; b=h1RC+iHszD/LLu/Z0GH6Ol0iS7ONh/f4rLAV/r9WTxCLx15au6BeFm0QOV/RtcqFuL glVnwbiA5MtDIQpJfyf2NtHEZdcLXAgFC7b4BCwPgqt2JoXgvbOvdAxf3Fw4SQ0hNpV/ hsvDia0sn5xfpIKceLEm633XlReCqXk+9JHqPzBHvBloaP1VgnYRM8LP0fQVjPgPK65A 50ISq8Srr3fRmzNdmnc9B2t0yjmvuuv8JUo3SR3TxowrSb+pukCh/bMhhBgS16BhejfJ je+VJcJrYH9qUCe6QJKxvhUpLncO8YFOVJpcjRy2m2UKtLbcasfwIiGzbaw7qAr4Bx2R wFFQ== X-Forwarded-Encrypted: i=1; AFNElJ/tEOWwOzDjOv4+Qdr36bwU5MZifd1ZRjxRPj2eCUq4S+YJrdMPfugXWC5oJ20C0EfQi2ptxacTtMI/DUQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwvxLrM7UMrbyOz3MqJ3gomScQpc24xiHpygAigcZP6tjJUUAj+ rm4k+fsFflEYRjLo5vkk4nGB4Hf3+0FVqjAn/ocTZzPNqBopgrYZA1bX X-Gm-Gg: Acq92OHSFNPBgN11D5dZKfEx1YW851UFmz5/S7A8Ztbt5aG8eWAC97le3eMVnQCOPwf GUC8181FE2CKkjtPYIdUMDG3BoDfMFZkZNoNX5vtD/k6MdPs9QWtteAG2hbTBnFp9/3j6X0X51e 0+Y7MUHVVKgrw5lVjGlP95Cjk2wGzr2h8MwFNrSd5V24H1J+EzvQkCSoKaf6soeKqYxV8L0HMNl MtZNW/x6LcintJJS194wBilanj3MObiTlGlNzWVfwyYkFAs2S245K8xw+7d2PbEfHSq1AT2PXsQ 1gev2jDiOd+trPxsAxIh2KU3pz/5ZzPP03mc73t3D+JkmeFimM4yQI9uZ/lvGOocD4NK2EWNZFj z8SFb2MuUVc0nsOKkoJ52qSCeFFZXXo5rh33ItBn+9gd8MzXO/LuA+0fk1Z14jU9+l0JkVLGfv6 tjH89oAkYAiJp6CauiGj3lWVh9BPsNgfya1ZzsQfIT12vRKXhljlFcS7QnWIVf X-Received: by 2002:a17:907:801:b0:bc2:9733:9ecc with SMTP id a640c23a62f3a-bd3e27ef0famr8796166b.32.1778621772132; Tue, 12 May 2026 14:36:12 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bcd9decf173sm507580066b.43.2026.05.12.14.36.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 14:36:11 -0700 (PDT) Date: Tue, 12 May 2026 22:36:09 +0100 From: David Laight To: David Howells Cc: netdev@vger.kernel.org, Hyunwoo Kim , Marc Dionne , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org, Jeffrey Altman , Jiayuan Chen , stable@vger.kernel.org Subject: Re: [PATCH net 2/3] rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg Message-ID: <20260512223609.57150707@pumpkin> In-Reply-To: <1072349.1778604723@warthog.procyon.org.uk> References: <20260512143835.13af8bc4@pumpkin> <20260511160753.607296-1-dhowells@redhat.com> <20260511160753.607296-3-dhowells@redhat.com> <1072349.1778604723@warthog.procyon.org.uk> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 12 May 2026 17:52:03 +0100 David Howells wrote: > David Laight wrote: ... > > > + size_t size = umin(round_up(sp->len, 32), 2048); > > > > Doesn't min() work? > > Actually, it should be umax() as I want the largest of the values (as Jeff > pointed out). I prefer using umin/umax for values that are known to be > unsigned as you don't get casting errors (see the number of places we end up > using min/max_t(, ...) when we should use umin/umax() instead) > and the compiler may generate better code as we've told it that it doesn't > have to worry about negatives. umin() and umax() are better than min_t() and max_t() (which is why I added them); but you lose the compile-time check in min() and max() that rejects comparisons where one side is unsigned and the compiler doesn't know that the other is always non-negative. Basically if you compare a signed 32bit value and an unsigned 64bit one with umin() the 32bit one is zero-extended to 64 bits. OTOH min_t(u64) will sign-extend the 32bit value and then treat it as unsigned. In both cases the onus is on the programmer to ensure the 32bit value isn't negative. For valid non-negative values the result is the same. Zero-extending is usually free, sign-extending is particularly horrid on 32bit. But it is better to use min() or max(). The compile-time tests will reject any cases where the integer promotion rules could convert a negative value to a large positive one. Note that the types no longer have to match. Code like this is (usually) ok: unsigned int blk_len = ...; int rval = fun(...); while (rval > 0) { u32 len = min(rval, blk_len); // process len bytes; rval -= len; } even though the types passed to min() differ in signedness the compiler's value tracking means it knows that rval can never become a large unsigned value - and min() uses that to allow it all through. -- David > > > That doesn't look right. > > If sp->len is bigger than 2048 the you keep allocating a new buffer > > and the call below overruns the allocated buffer. > > Yep - see the aforementioned umax comment. > > David >