From nobody Tue Mar 3 05:11:13 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 65118383C74 for ; Mon, 2 Mar 2026 18:46:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477195; cv=none; b=TFfqt2wQ6UKgCsblpPcsJ+D0k+bG4v9JOYx6bF07qxcvcHIPp6/5BtjV6Rl4hZu33RC/HkTmpdnB1pG3vo/zkiW0rWLKx6RCKXFTAYoLYxLGqWMkpaozCafqICROreONXCr5IvawD89IPWXwfy/FyP9LM0oV+ml3O09ZwGORdH4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772477195; c=relaxed/simple; bh=jmRYPBs4qnWxa2oEzq7iX9LJGBD9xCCVJOZk0JJE8co=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M2lSzSU1hztbs1WjHheZUFNOCQqH4d3j6at9TfamqRjkbRIDQbAO2t/uHtRHotc3mAsJT1emeWajy2JVbyjWKAIRLVjJs0C6fIq50GIGxd/MWwQpjr13DZAyKua65eVHUkQyPHramxXY17o+aCl9KfQSrwt2CpJbttxaUECxYR8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=nMNkKC3j; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="nMNkKC3j" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772477195; x=1804013195; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jmRYPBs4qnWxa2oEzq7iX9LJGBD9xCCVJOZk0JJE8co=; b=nMNkKC3jJIURCcTTS/ZlNt5TXBO8NbclOGbkjw+tgbtjrdr5JuC1U4Gy Krk55X0Qq74mxW2Ny7burWlVgDhf0mDS/Tq8VUrZbKhELPEMrntXx2KGc z60ipZtj5KrOhMJ5/nx7WZP+JqdnECQ63YaAOqZ2YWYXcS38D94MnHi5j KauGGHhyhSWT/kQe776s/5A9qfuxJ5XRmNFgK54f482GWKxhdZLsMEZ+I I3TONNFjWOH5kBOj9sK0fdjhWtRGrnvjKXNPSyhdofdQt2TUi7pvACsVO dyNPOdAhCHvxgGe6OuoFMjg5ZPTEhZ9Qt/SRxKuoHf3Ldeim3mT9HXFc5 A==; X-CSE-ConnectionGUID: 4Zj6h77gRSyCkL43I4ke6A== X-CSE-MsgGUID: OkAdd+ApQVmUe4qdWF2SJQ== X-IronPort-AV: E=McAfee;i="6800,10657,11717"; a="84135508" X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="84135508" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:27 -0800 X-CSE-ConnectionGUID: U/uMiH4NQX6JTeOuEeL0aQ== X-CSE-MsgGUID: ZrK4N+3JSg+Vdk0zP48UFw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,320,1763452800"; d="scan'208";a="255604101" Received: from rchatre-desk1.jf.intel.com ([10.165.154.99]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2026 10:46:26 -0800 From: Reinette Chatre To: tony.luck@intel.com, james.morse@arm.com, Dave.Martin@arm.com, babu.moger@amd.com, bp@alien8.de, tglx@linutronix.de, dave.hansen@linux.intel.com Cc: x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fustini@kernel.org, fenghuay@nvidia.com, peternewman@google.com, linux-kernel@vger.kernel.org, patches@lists.linux.dev, reinette.chatre@intel.com Subject: [PATCH 09/11] fs/resctrl: Use stricter checks on input to cpus/cpus_list file Date: Mon, 2 Mar 2026 10:46:15 -0800 Message-ID: X-Mailer: git-send-email 2.50.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Callbacks handling writes to resctrl files are called via kernfs_fop_write_iter() that ensures that the resctrl callback is never called with a NULL buffer. Even if user space issues a write() with a NULL buffer and zero count the resctrl callback receives a valid buffer terminated with '\0' and the number of bytes parameter set to zero. The NULL buffer check at the beginning of rdtgroup_cpus_write(), while making no assumptions about caller behavior, is not useful. An empty buffer is transformed into an empty cpumask that is passed through entire flow that results in no changes. Ensure that the user provided buffer contains some data before attempting to parse it using the same check as other resctrl files (the familiar "nbytes =3D=3D 0"). The custom is for resctrl file callbacks to fail on an empty buffer and this brings interactions with the cpus/cpus_list file in line with this custom. The risk is that if there exists a user space that uses empty writes to this specific file then those successful interactions will start failing. Exit right away if there was no failure yet no cpumask could be created from the input. It is of no use to pass an empty cpumask through the entire flow, just return with success to short-circuit the existing behavior. Signed-off-by: Reinette Chatre --- fs/resctrl/rdtgroup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 933f6ae26d59..f33a50c545bc 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -515,7 +515,7 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_f= ile *of, struct rdtgroup *rdtgrp; int ret; =20 - if (!buf) + if (!buf || nbytes =3D=3D 0) return -EINVAL; =20 if (!zalloc_cpumask_var(&tmpmask, GFP_KERNEL)) @@ -555,6 +555,9 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_f= ile *of, goto unlock; } =20 + if (cpumask_empty(newmask)) + goto unlock; + /* check that user didn't specify any offline cpus */ cpumask_andnot(tmpmask, newmask, cpu_online_mask); if (!cpumask_empty(tmpmask)) { --=20 2.50.1