From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (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 3C3951FC0F8; Fri, 17 Jan 2025 10:55:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.197 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737111312; cv=none; b=tua/8tVdLUUmhngoEBbGndGvPQNfIT6DtUBppBO4WjiaCx2sU2H3wR5P4HkI0xLWiObdZXjLQng4qW7KeQ4No+QJ6nuPyXDmbGIrifCkqZdmpYQwyAGUQ5gtveSS81/cJYZZ+Yba4+rE9IJsHCHRbDUSFO5vidxFfCKDdFbAxPQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737111312; c=relaxed/simple; bh=FBzsdBIU6YumukfUbJWK1ggJJP5iD4qS7v04qulwPaA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=F2//jdeg78plgblLNgmy2L1mm1liX1StFAkRuggFF1GGkW1P01aN7mmqMmTG7FbRxEpXCnhCH+x0r5phjgG1q1bAhRrpr7wQXu0kxBww8TK6JLzcg9dp9eZh7RBLk2cWUMiNxp+ZBpn5hLr85uw4HIA3a8DFyAEm1eMzZ1xAw2c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=clip-os.org; spf=pass smtp.mailfrom=clip-os.org; dkim=pass (2048-bit key) header.d=clip-os.org header.i=@clip-os.org header.b=Vw/TBJFa; arc=none smtp.client-ip=217.70.183.197 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=clip-os.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=clip-os.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=clip-os.org header.i=@clip-os.org header.b="Vw/TBJFa" Received: by mail.gandi.net (Postfix) with ESMTPSA id D58AA1C000A; Fri, 17 Jan 2025 10:55:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clip-os.org; s=gm1; t=1737111308; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FBzsdBIU6YumukfUbJWK1ggJJP5iD4qS7v04qulwPaA=; b=Vw/TBJFawwg898J6COZc5ljKY4LDa/TcrvcYPaMJSQETkVfnwDM8S7sbbNXySlBy9odDrq NDX8oPvHVqo01h6sZUtPiqxR/0ebYy/uV76ghW3S5lItDkwAi4wlH/PwDk/Eq8DKCCI0Ai 59VIP2TxbfIRG6xzBLMmke1Wbv3+xLCRfglPbedZbaJVixtZGHawrCOtW9fCjSp3FB9weC cv9f2oPmtBMWQBDtXPOek+PhB6I4Ol3Qnvp/LVuraibLLt1FDskepB5wqboJPdI+rgEZxY WFq8SuqpLyvOECrksKAozreGD5/gru+syEtaVi4e0YrisxrBBzo5P08gpgK85Q== Message-ID: Date: Fri, 17 Jan 2025 11:55:05 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] coredump: Fixes core_pipe_limit sysctl proc_handler To: Kees Cook Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Nicolas Bouchinet , Greg Kroah-Hartman , Jiri Slaby , Alexander Viro , Christian Brauner , Jan Kara , Luis Chamberlain , Joel Granados , Andrew Morton , Neil Horman , Lin Feng , Theodore Ts'o References: <20250115132211.25400-1-nicolas.bouchinet@clip-os.org> <20250115132211.25400-2-nicolas.bouchinet@clip-os.org> <202501151630.87A0A8E7C4@keescook> Content-Language: en-US From: Nicolas Bouchinet In-Reply-To: <202501151630.87A0A8E7C4@keescook> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-GND-Sasl: nicolas.bouchinet@clip-os.org On 1/16/25 1:32 AM, Kees Cook wrote: > On Wed, Jan 15, 2025 at 02:22:08PM +0100, nicolas.bouchinet@clip-os.org wrote: >> Any negative write or >= to INT_MAX in core_pipe_limit sysctl would >> hypothetically allow a user to create very high load on the system by >> running processes that produces a coredump in case the core_pattern >> sysctl is configured to pipe core files to user space helper. >> Memory or PID exhaustion should happen before but it anyway breaks the >> core_pipe_limit semantic. > Isn't this true for "0" too (the default)? I'm not opposed to the change > since it makes things more clear, but I don't think the >=INT_MAX > problem is anything more than "functionally identical to 0". :) Uhm, I think your right, its seems to be functionally identical. 0 codepath slightly differs from > 0 though since it won't trigger wait_for_dump_helpers(). Thanks for your review, Nicolas > > Reviewed-by: Kees Cook >