From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 264D13DB63F for ; Wed, 13 May 2026 08:13:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778660034; cv=none; b=schWe2x0oixcsh9UYjxCecBveJEJdNVHc2uWlWuhBOruwk/Fr7/N69yB5BexdrOGcMg5bvZLFYX0eIr6zRaf62QSh++tRdI+WY2GltgY6+o8QIKCUnBiwrLoDK4NO2jVbqS2ER0sA+CLClXvVxg8eaVmgNVdC9Y6roSDm3KEvDM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778660034; c=relaxed/simple; bh=kmni9OLhg4Pd5n62/ER2xoJKPdcU2TOdP1z0TI3HiTM=; h=From:In-Reply-To:References:To:Cc:Subject:MIME-Version: Content-Type:Date:Message-ID; b=g4guY/k49ibk1i2JLUKqzQfIxIY9+e3SIlV7+ySUgcz8P/iQu/cs1bxIHloSCyhV+mHmVJXDdrP4+u7t8Fc/YYXmQ2w949GTv6w8cawWgw98XqURcfpScwbprxvRM2LghdkaKN5KFOEcHYP0Pnu5zy81P7A8FckVnXaXZ7vQons= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=GyjXt7jX; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GyjXt7jX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778660028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7jMVBsE7V/XEqCjzIOK4vL1Dn6WnzW8J5Vfp3OVDYBM=; b=GyjXt7jXgjEcX95WcZM3iZzmhFS/P5iO26O9XpQvlWc/LWiIIAgp627zfqbWxdEcMlEGKA ORZB4yL8o7SoAtzjnbagR4Cw/aJ1b7QhaasxW3cvdQPjNqQb2K31e2kkq8spamiu65fIlN 2Y+kfsf6fexeYfzvD1sR/kb4Of22Q78= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-550-oKIoDh_dMDOuYwnVtVm4_A-1; Wed, 13 May 2026 04:13:47 -0400 X-MC-Unique: oKIoDh_dMDOuYwnVtVm4_A-1 X-Mimecast-MFC-AGG-ID: oKIoDh_dMDOuYwnVtVm4_A_1778660025 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id F37CD19560B2; Wed, 13 May 2026 08:13:44 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.44.48.83]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id EAE4B1800349; Wed, 13 May 2026 08:13:40 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1354628.1778659274@warthog.procyon.org.uk> References: <1354628.1778659274@warthog.procyon.org.uk> <437CCB8A-5333-4349-B120-A103B1F0E617@auristor.com> <20260511160753.607296-1-dhowells@redhat.com> <20260511160753.607296-3-dhowells@redhat.com> To: Jeffrey Altman Cc: dhowells@redhat.com, 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, 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 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1354985.1778660019.1@warthog.procyon.org.uk> Date: Wed, 13 May 2026 09:13:39 +0100 Message-ID: <1354986.1778660019@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 David Howells wrote: > > > + kfree(call->rx_dec_buffer); > > > > It might be better to avoid deallocating the buffer on the error > > path and permit it to be freed during normal call (or call channel) > > deallocation. > > Hmmm. But I then need some other way to note that the buffer is no longer > occupied by valid data. I suppose I could set ->rx_dec_offset to USHRT_MAX. Actually, I'm not sure that just freeing the buffer is all that bad. If skb_copy_bits() fails (ie. EFAULT), then the sk_buff is unrecoverably broken somehow and the app will may have to abandon the call. Possibly the call should be aborted directly here. The case really shouldn't happen and probably merits a pr_warn(). If ->verify_packet() fails with ENOMEM, then it's retryable. Releasing the buffer temporarily might help the system. If ->verify_packet() fails with anything else, then the call should have been aborted. David