[PATCH] sched/core: check format and overflows in cgroup2 cpu.max

[PATCH] sched/core: check format and overflows in cgroup2 cpu.max

[Konstantin Khlebnikov]

Cgroup2 interface for cpu bandwidth limit has some flaws:

- on stack buffer overflow
- no checks for valid format or trailing garbage
- no checks for integer overflows

This patch fixes all these flaws.

Fixes: 0d5936344f30 ("sched: Implement interface for cgroup unified hierarchy")
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
---
 kernel/sched/core.c |   29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5f46aa335b28..123b1910bc2e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6947,19 +6947,34 @@ static int __maybe_unused cpu_period_quota_parse(char *buf,
 						 u64 *periodp, u64 *quotap)
 {
 	char tok[21];	/* U64_MAX */
+	int ret, len;
 
-	if (!sscanf(buf, "%s %llu", tok, periodp))
+	if (sscanf(buf, "%20s %n", tok, &len) != 1)
 		return -EINVAL;
 
-	*periodp *= NSEC_PER_USEC;
-
-	if (sscanf(tok, "%llu", quotap))
-		*quotap *= NSEC_PER_USEC;
-	else if (!strcmp(tok, "max"))
+	ret = kstrtou64(tok, 10, quotap);
+	if (ret) {
+		if (strcmp(tok, "max"))
+			return ret;
 		*quotap = RUNTIME_INF;
-	else
+	} else if (*quotap <= U64_MAX / NSEC_PER_USEC) {
+		*quotap *= NSEC_PER_USEC;
+	} else
 		return -EINVAL;
 
+	buf += len;
+	if (*buf) {
+		if (sscanf(buf, "%20s %n", tok, &len) != 1 || buf[len])
+			return -EINVAL;
+		ret = kstrtou64(tok, 10, periodp);
+		if (ret)
+			return ret;
+		if (*periodp > U64_MAX / NSEC_PER_USEC)
+			return -EINVAL;
+	}
+
+	*periodp *= NSEC_PER_USEC;
+
 	return 0;
 }
 

Re: [PATCH] sched/core: check format and overflows in cgroup2 cpu.max

[Tejun Heo]

Hello,

On Wed, Feb 27, 2019 at 11:13:21AM +0300, Konstantin Khlebnikov wrote:
> Cgroup2 interface for cpu bandwidth limit has some flaws:
> 
> - on stack buffer overflow
> - no checks for valid format or trailing garbage
> - no checks for integer overflows
> 
> This patch fixes all these flaws.

Ditto as the blkio patch.  Unless there is a correctness problem, my
preference is towards keeping the parsing functions simple and I don't
think the kernel needs to play the role of strict input verifier here
as long as the only foot getting shot is the user's own.

Thanks.

-- 
tejun

Re: [PATCH] sched/core: check format and overflows in cgroup2 cpu.max

[Konstantin Khlebnikov]

On 05.03.2019 18:57, Tejun Heo wrote:
> Hello,
> 
> On Wed, Feb 27, 2019 at 11:13:21AM +0300, Konstantin Khlebnikov wrote:
>> Cgroup2 interface for cpu bandwidth limit has some flaws:
>>
>> - on stack buffer overflow
>> - no checks for valid format or trailing garbage
>> - no checks for integer overflows
>>
>> This patch fixes all these flaws.
> 
> Ditto as the blkio patch.  Unless there is a correctness problem, my
> preference is towards keeping the parsing functions simple and I don't
> think the kernel needs to play the role of strict input verifier here
> as long as the only foot getting shot is the user's own.

IMHO non-strict interface more likely hides bugs and could cause problems for future changes.

Here is only only one fatal bug - buffer overflow in sscanf because %s has no limit.

Strict validation could be done as more strict sscanf variant or some kind of extension for format string.

> 
> Thanks.
> 

Re: [PATCH] sched/core: check format and overflows in cgroup2 cpu.max

[Tejun Heo]

Hello, Konstantin.

On Tue, Mar 05, 2019 at 08:03:24PM +0300, Konstantin Khlebnikov wrote:
> >Ditto as the blkio patch.  Unless there is a correctness problem, my
> >preference is towards keeping the parsing functions simple and I don't
> >think the kernel needs to play the role of strict input verifier here
> >as long as the only foot getting shot is the user's own.
> 
> IMHO non-strict interface more likely hides bugs and could cause
> problems for future changes.
> 
> Here is only only one fatal bug - buffer overflow in sscanf because
> %s has no limit.

Ah, indeed.  Can you please post a patch to fix that problem first?

> Strict validation could be done as more strict sscanf variant or
> some kind of extension for format string.

I don't necessarily disagree with you; however, what often ends up
with these manually crafted parsing approach are 1. code which is
unnecessarily difficult to follow 2. different subset of validations
and parsing bugs (of course) everywhere.

Given the above, I tend to lean towards dump sscanf() parsing.  If we
wanna improve the situation, I think the right thing to do is either
improving sscanf or introducing new helpers to parse these things
rather than hand-crafting each site.  It is really error-prone.

Thanks.

-- 
tejun

Re: [PATCH] sched/core: check format and overflows in cgroup2 cpu.max

[Peter Zijlstra]

On Wed, Mar 06, 2019 at 08:11:54AM -0800, Tejun Heo wrote:
> Hello, Konstantin.
> 
> On Tue, Mar 05, 2019 at 08:03:24PM +0300, Konstantin Khlebnikov wrote:
> > >Ditto as the blkio patch.  Unless there is a correctness problem, my
> > >preference is towards keeping the parsing functions simple and I don't
> > >think the kernel needs to play the role of strict input verifier here
> > >as long as the only foot getting shot is the user's own.
> > 
> > IMHO non-strict interface more likely hides bugs and could cause
> > problems for future changes.
> > 
> > Here is only only one fatal bug - buffer overflow in sscanf because
> > %s has no limit.
> 
> Ah, indeed.  Can you please post a patch to fix that problem first?
> 
> > Strict validation could be done as more strict sscanf variant or
> > some kind of extension for format string.
> 
> I don't necessarily disagree with you; however, what often ends up
> with these manually crafted parsing approach are 1. code which is
> unnecessarily difficult to follow 2. different subset of validations
> and parsing bugs (of course) everywhere.
> 
> Given the above, I tend to lean towards dump sscanf() parsing.  If we
> wanna improve the situation, I think the right thing to do is either
> improving sscanf or introducing new helpers to parse these things
> rather than hand-crafting each site.  It is really error-prone.

Always use a field width specifier with %s.  Which is exactly what the
proposed patch did IIRC.

Maybe that's something checkpatch could warn about.

Re: [PATCH] sched/core: check format and overflows in cgroup2 cpu.max

[Konstantin Khlebnikov]

On 06.03.2019 19:48, Peter Zijlstra wrote:
> On Wed, Mar 06, 2019 at 08:11:54AM -0800, Tejun Heo wrote:
>> Hello, Konstantin.
>>
>> On Tue, Mar 05, 2019 at 08:03:24PM +0300, Konstantin Khlebnikov wrote:
>>>> Ditto as the blkio patch.  Unless there is a correctness problem, my
>>>> preference is towards keeping the parsing functions simple and I don't
>>>> think the kernel needs to play the role of strict input verifier here
>>>> as long as the only foot getting shot is the user's own.
>>>
>>> IMHO non-strict interface more likely hides bugs and could cause
>>> problems for future changes.
>>>
>>> Here is only only one fatal bug - buffer overflow in sscanf because
>>> %s has no limit.
>>
>> Ah, indeed.  Can you please post a patch to fix that problem first?

Done.
Please see [PATCH] sched/core: fix buffer overflow in cgroup2 property cpu.max

>>
>>> Strict validation could be done as more strict sscanf variant or
>>> some kind of extension for format string.
>>
>> I don't necessarily disagree with you; however, what often ends up
>> with these manually crafted parsing approach are 1. code which is
>> unnecessarily difficult to follow 2. different subset of validations
>> and parsing bugs (of course) everywhere.
>>
>> Given the above, I tend to lean towards dump sscanf() parsing.  If we
>> wanna improve the situation, I think the right thing to do is either
>> improving sscanf or introducing new helpers to parse these things
>> rather than hand-crafting each site.  It is really error-prone.

I'm playing with sscanf right now.

Both problems (integer overflows and matching end of string)
are relatively easy to fix without breaking sane compatibility.

> 
> Always use a field width specifier with %s.  Which is exactly what the
> proposed patch did IIRC.
> 
> Maybe that's something checkpatch could warn about.
> 

This could be done mandatory.
In-kernel sscanf always requires width for "%[...]".