In the "range:used/group" form bitmap_set_region() walks the range with
for (start = r->start; start <= r->end; start += r->group_len)
where all values are unsigned int. bitmap_getnum() accepts any group
size up to UINT_MAX, and bitmap_check_region() only requires it to be
non-zero and at least the used size. If start + group_len exceeds
UINT_MAX, start wraps around to a small value that is still <= end, and
bits below the start of the range get set:
"1-1:1/4294967295" -> bits 0,1 (expected bit 1)
"15-15:1/4294967281" -> bits 0,15 (expected bit 15)
The loop still terminates, because start keeps decreasing until it
wraps past zero again, but the resulting mask contains bits outside
the requested range.
This needs a group size within 'start' of UINT_MAX, so it is unlikely
to be hit by accident; all bits set stay below the end of the range,
so there is no out-of-bounds write.
A group larger than the range simply means that the range contains a
single group, so stop the walk when the next group would start beyond
UINT_MAX.
Fixes: 0a5ce0831d ("lib/bitmap.c: make bitmap_parselist() thread-safe and much faster")
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
bitmap_parse_region() checks that every region ends at a separator
(',', whitespace, '\n' or '\0'), except in the "range:used/group" form:
after parsing the group size it returns the pointer to the following
character without looking at it. The caller then starts a new region
at that character.
Before 'N' and 'all' were accepted as region starts this happened to be
harmless, because any other character would fail to parse as a new
region. Now text directly following the group size is silently parsed
as another region:
"0-7:1/2N" -> bits 0,2,4,6,7 (nbits = 8), returns 0
"0-7:1/2all" -> all bits set, returns 0
while "0-7N", "5N" or "0-7:1/2x" are correctly rejected with -EINVAL.
bitmap_parselist() is documented to return -EINVAL for an invalid
character. It parses cpu lists from sysfs, cgroup cpuset files and
boot parameters such as isolcpus= and nohz_full=, so a typo there is
accepted and yields a different mask than intended.
Check for the end of the region after the group size as well, like the
other forms do.
Fixes: 2c4885d24e ("lib: bitmap: support "N" as an alias for size of bitmap")
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
bitmap_parse() is documented to return -EINVAL for illegal characters,
and it does so everywhere except when the illegal character directly
precedes a chunk of exactly eight hex digits.
bitmap_get_x32_reverse() parses a chunk from right to left. After it
has consumed eight digits it looks at one more character: a hex digit
means the chunk is wider than 32 bits and -EOVERFLOW is returned. Any
other character is silently consumed as if it were a separator, and the
remaining input is parsed as the next chunk. As a result:
"x12345678" -> 0x12345678, returns 0 (expected -EINVAL)
"1g12345678" -> 0x1_12345678, returns 0 (expected -EINVAL)
"0x0000000f" -> 0xf, returns 0, while "0xf" returns -EINVAL
bitmap_parse() backs cpumask_parse() and cpumask_parse_user(), so the
same inconsistency is visible when writing masks such as
/proc/irq/*/smp_affinity or the network queue rps_cpus/xps_cpus files.
__bitmap_parse(), which this function replaced in commit 2d6261583b
("lib: rework bitmap_parse()"), rejected all three strings with -EINVAL,
and a "0x" prefix is accepted today only when exactly eight digits
follow it, so no reliably working input is lost.
When the loop falls through, *end is known to be a non-separator
character inside the buffer, so return -EOVERFLOW if it is a hex digit
and -EINVAL otherwise.
Fixes: 2d6261583b ("lib: rework bitmap_parse()")
Assisted-by: LLM
Signed-off-by: Shashank Mohan Jain <jain.sm@gmail.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
lib/bitmap.c and corresponding include/linux/bitmap.h are intended to
hold functions related to operations on bitmaps, like bitmap_shift or
bitmap_set. Historically, some string-related operations like
bitmap_parse are also reside in lib/bitmap.c.
Now that the subsystem evolves, string-related bitmap operations became a
significant part of the file. Because they are quite different from the
other bitmap functions by nature, it's worth to split them to a separate
source/header files.
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
CC: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
