From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2B5E72C1788 for ; Mon, 29 Jun 2026 02:12:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782699179; cv=none; b=W2yhwzmpDG/ReLa0KGiu09INzgpR+uX0lVMlCg6QGWsQGqLSvAxMvc6623ecGouFY8uK3g1KFFZlzAleDnSXHTPWMgqhD5VR8s4P06CPa8qsX840GmVExk8YE9XlVHbpSQmDsi0PeswhXnJnZM0Cg9qq7KU5WdcCY2zdTlpWaSY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782699179; c=relaxed/simple; bh=3SJSMySevobT+Om3Ep/yPCwu8Uh9GZdqU0dIXSbjCNQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZvkkZHvYoqa+2fwoYtI8SEiijLmukXy/ep+hcodsFr/GY8EHiSMb4TSuMMDfQzd1qIRqtmx6YguVZsVojJ4WQjwxcKZw4oNvsFjeVTYne+gPo+fVBynJt6jonHFXZ3ClZX1bOnLwnqH7mMSpjgjR3a+i94F5wLPXEEQcimG/ND0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Received: from macsyma.thunk.org (pool-173-48-111-178.bstnma.fios.verizon.net [173.48.111.178]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 65T2Cb7u018385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Jun 2026 22:12:38 -0400 Received: by macsyma.thunk.org (Postfix, from userid 15806) id 878377C0209; Sun, 28 Jun 2026 22:12:37 -0400 (EDT) Date: Sun, 28 Jun 2026 22:12:37 -0400 From: "Theodore Tso" To: Jakub Stasiak Cc: "Jason A. Donenfeld" , linux-kernel@vger.kernel.org Subject: Re: [PATCH] random: reject negative RNDADDENTROPY sizes early Message-ID: References: <9C982B79-FC02-49E0-8021-D1E41F249E45@stasiak.at> 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-Disposition: inline In-Reply-To: <9C982B79-FC02-49E0-8021-D1E41F249E45@stasiak.at> On Sun, Jun 28, 2026 at 01:42:27PM -0500, Jakub Stasiak wrote: > Reject negative len values at the ioctl boundary instead. This avoids > relying on the later import and write paths, and prevents an invalid > request from mixing user data into the pool at the clamped length > instead of the requested len before returning -EFAULT. Consider this > defense in depth. The patch isn't wrong per se, but defense in depth against what? This ioctl() requires root privileges, and so it's not something where we would need to worry about an attacker passing in invalid data to the ioctl. If you have CAP_SYS_ADMIN, there is far more mischief you could do.... - Ted