sched/core: check format and overflows in cgroup2 cpu.max
diff mbox series

Message ID 155125520155.293746.7017401430432481979.stgit@buzz
State New, archived
Headers show
Series
  • sched/core: check format and overflows in cgroup2 cpu.max
Related show

Commit Message

Konstantin Khlebnikov Feb. 27, 2019, 8:13 a.m. UTC
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(-)

Comments

Tejun Heo March 5, 2019, 3:57 p.m. UTC | #1
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.
Konstantin Khlebnikov March 5, 2019, 5:03 p.m. UTC | #2
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.
>
Tejun Heo March 6, 2019, 4:11 p.m. UTC | #3
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.
Peter Zijlstra March 6, 2019, 4:48 p.m. UTC | #4
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.
Konstantin Khlebnikov March 6, 2019, 5:21 p.m. UTC | #5
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 "%[...]".

Patch
diff mbox series

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;
 }