llc-coloring: improve checking while parsing

We can easily avoid the risk of wrapping UINT_MAX <-> 0 by applying a
check against the compile-time-constant maximum number of colors.

Additionally the overflow checks suffered from an off-by-1, as the parsed
ranges are inclusive (e.g. end == start being possible, requiring 1 array
slot, while availability of 0 slots was checked in that case).

Fixes: 6cdea3444e ("xen/arm: add Dom0 cache coloring support")
Reported-by: Mykola Kvach <xakep.amatop@gmail.com>
Reported-by: Kamil Frankowicz <kamil.frankowicz@cert.pl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

xen/common: llc-coloring: Fix off-by-one in parse_color_config()

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
cba8a584de that regressed the behavior (i.e. don't add 1).

Fixes: cba8a584de ("llc-coloring: improve checking while parsing")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
master commit: cba8a584de
master date: 2026-04-07 13:52:44 +0200
master commit: dc28f531e6
master date: 2026-04-10 12:14:05 +0200

xen/common/llc-coloring.c

@@ -76,7 +76,8 @@ static int __init parse_color_config(const char *buf, unsigned int colors[],
         else                /* Single value */
             end = start;
 
-        if ( start > end || (end - start) > (UINT_MAX - *num_colors) ||
+        if ( end >= NR_LLC_COLORS || start > end ||
+             (end - start) >= (UINT_MAX - *num_colors) ||
              (*num_colors + (end - start)) >= max_num_colors )
             return -EINVAL;