The check uses (*num_colors + (end - start + 1)) >= max_num_colors, which
rejects a configuration where exactly max_num_colors colors are specified.
For example, if max_num_colors is 4 and *num_colors is 0, a range "0-3"
gives (end - start + 1) = 4, and (0 + 4) >= 4 is true, incorrectly
returning -EINVAL.
Fix this by switching the overflow condition to the state before commit
cba8a584de17 that regressed the behavior (i.e. don't add 1).
Fixes: cba8a584de17 ("llc-coloring: improve checking while parsing")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v2:
- extract from series
- undo the overflow change made by cba8a584de17
---
xen/common/llc-coloring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/llc-coloring.c b/xen/common/llc-coloring.c
index eb7c72b24023..6dc614739a98 100644
--- a/xen/common/llc-coloring.c
+++ b/xen/common/llc-coloring.c
@@ -78,7 +78,7 @@ static int __init parse_color_config(const char *buf, unsigned int colors[],
if ( end >= NR_LLC_COLORS || start > end ||
(end - start) >= (UINT_MAX - *num_colors) ||
- (*num_colors + (end - start + 1)) >= max_num_colors )
+ (*num_colors + (end - start)) >= max_num_colors )
return -EINVAL;
/* Colors are range checked in check_colors() */
--
2.43.0