From nobody Fri Dec 19 03:20:45 2025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3093E784AC for ; Mon, 2 Oct 2023 13:34:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237451AbjJBNeI (ORCPT ); Mon, 2 Oct 2023 09:34:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236712AbjJBNeC (ORCPT ); Mon, 2 Oct 2023 09:34:02 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F291FB4; Mon, 2 Oct 2023 06:33:59 -0700 (PDT) Date: Mon, 02 Oct 2023 13:33:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1696253638; h=from:from:sender:sender:reply-to: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=P0p2vR7BHS9RuTDzTxnJMgzinuQb+pJ7BDAsPRKwgIQ=; b=R6yncCiP0jLQi4K/8Pj8jlk/k7VAeNo2Ua+3vwgfYrqiOW/bB4kAgxVdr0xxHrPccW0n/g TJbfj+JgkivLmtF3MtVKitGhXe5xm8dNjloWRw6zNO4ESuGE+7+tby+r9bG05Y2bxxaWo6 3RZ//VbWRiIZvASn605bygrK3Ms+w5QhHZsWN9hbgYRmRlizLp8TtZLPU4qwpKv6WKHBIY lxq5uiSXywDzkreWi7eXvM5lL6FOT6otRfiHtaG/VUe+V2XtEMEmT4/wVNtG4pcMVemMo2 kc3A1rRPEM70Xy0ywJwv0alw5dNHMJu1tbne8HYMyMKGvBIJAoUCE6j6HgT0qQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1696253638; h=from:from:sender:sender:reply-to: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=P0p2vR7BHS9RuTDzTxnJMgzinuQb+pJ7BDAsPRKwgIQ=; b=DVt8K2eyBHkvQmmPTMKC759va635RCTbRzcYNHQb/dZ8WVRX7v0bpfqVltInNQOVEBCBr+ LMjZZpusCSwMGaDg== From: "tip-bot2 for Cyril Hrubis" Sender: tip-bot2@linutronix.de Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: sched/core] sched/rt: Disallow writing invalid values to sched_rt_period_us Cc: Cyril Hrubis , Ingo Molnar , x86@kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20231002115553.3007-2-chrubis@suse.cz> References: <20231002115553.3007-2-chrubis@suse.cz> MIME-Version: 1.0 Message-ID: <169625363764.3135.15928031760457395657.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the sched/core branch of tip: Commit-ID: 079be8fc630943d9fc70a97807feb73d169ee3fc Gitweb: https://git.kernel.org/tip/079be8fc630943d9fc70a97807feb73d1= 69ee3fc Author: Cyril Hrubis AuthorDate: Mon, 02 Oct 2023 13:55:51 +02:00 Committer: Ingo Molnar CommitterDate: Mon, 02 Oct 2023 15:15:56 +02:00 sched/rt: Disallow writing invalid values to sched_rt_period_us The validation of the value written to sched_rt_period_us was broken because: - the sysclt_sched_rt_period is declared as unsigned int - parsed by proc_do_intvec() - the range is asserted after the value parsed by proc_do_intvec() Because of this negative values written to the file were written into a unsigned integer that were later on interpreted as large positive integers which did passed the check: if (sysclt_sched_rt_period <=3D 0) return EINVAL; This commit fixes the parsing by setting explicit range for both perid_us and runtime_us into the sched_rt_sysctls table and processes the values with proc_dointvec_minmax() instead. Alternatively if we wanted to use full range of unsigned int for the period value we would have to split the proc_handler and use proc_douintvec() for it however even the Documentation/scheduller/sched-rt-group.rst describes the range as 1 to INT_MAX. As far as I can tell the only problem this causes is that the sysctl file allows writing negative values which when read back may confuse userspace. There is also a LTP test being submitted for these sysctl files at: http://patchwork.ozlabs.org/project/ltp/patch/20230901144433.2526-1-chrub= is@suse.cz/ Signed-off-by: Cyril Hrubis Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20231002115553.3007-2-chrubis@suse.cz --- kernel/sched/rt.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 3b627ab..88fc986 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -37,6 +37,8 @@ static struct ctl_table sched_rt_sysctls[] =3D { .maxlen =3D sizeof(unsigned int), .mode =3D 0644, .proc_handler =3D sched_rt_handler, + .extra1 =3D SYSCTL_ONE, + .extra2 =3D SYSCTL_INT_MAX, }, { .procname =3D "sched_rt_runtime_us", @@ -44,6 +46,8 @@ static struct ctl_table sched_rt_sysctls[] =3D { .maxlen =3D sizeof(int), .mode =3D 0644, .proc_handler =3D sched_rt_handler, + .extra1 =3D SYSCTL_NEG_ONE, + .extra2 =3D SYSCTL_INT_MAX, }, { .procname =3D "sched_rr_timeslice_ms", @@ -2935,9 +2939,6 @@ static int sched_rt_global_constraints(void) #ifdef CONFIG_SYSCTL static int sched_rt_global_validate(void) { - if (sysctl_sched_rt_period <=3D 0) - return -EINVAL; - if ((sysctl_sched_rt_runtime !=3D RUNTIME_INF) && ((sysctl_sched_rt_runtime > sysctl_sched_rt_period) || ((u64)sysctl_sched_rt_runtime * @@ -2968,7 +2969,7 @@ static int sched_rt_handler(struct ctl_table *table, = int write, void *buffer, old_period =3D sysctl_sched_rt_period; old_runtime =3D sysctl_sched_rt_runtime; =20 - ret =3D proc_dointvec(table, write, buffer, lenp, ppos); + ret =3D proc_dointvec_minmax(table, write, buffer, lenp, ppos); =20 if (!ret && write) { ret =3D sched_rt_global_validate();