On 2/17/22 19:40, liuyuntao wrote:
> On 17 Feb 2022 15:42:18 -0800, Mike Kravetz wrote:
>> Recently introduced code allows numa nodes to be specified on the
>> kernel command line for hugetlb allocations or CMA reservations. The
>> node values are user specified and used as indicies into arrays. This
>> generated the following smatch warnings:
>>
>> mm/hugetlb.c:4170 hugepages_setup() warn: potential spectre issue 'default_hugepages_in_node' [w]
>> mm/hugetlb.c:4172 hugepages_setup() warn: potential spectre issue 'parsed_hstate->max_huge_pages_node' [w]
>> mm/hugetlb.c:6898 cmdline_parse_hugetlb_cma() warn: potential spectre issue 'hugetlb_cma_size_in_node' [w] (local cap)
>>
>> Clean up by using array_index_nospec to sanitize array indicies.
>>
>> Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
>> ---
>> mm/hugetlb.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 1f0cca036f7f..6b14d0791cb4 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -31,6 +31,7 @@
>> #include <linux/llist.h>
>> #include <linux/cma.h>
>> #include <linux/migrate.h>
>> +#include <linux/nospec.h>
>>
>> #include <asm/page.h>
>> #include <asm/pgalloc.h>
>> @@ -4161,7 +4162,7 @@ static int __init hugepages_setup(char *s)
>> }
>> if (tmp >= nr_online_nodes)
>> goto invalid;
>> - node = tmp;
>> + node = array_index_nospec(tmp, nr_online_nodes);
>> p += count + 1;
>> /* Parse hugepages */
>> if (sscanf(p, "%lu%n", &tmp, &count) != 1)
>> @@ -6889,9 +6890,9 @@ static int __init cmdline_parse_hugetlb_cma(char *p)
>> break;
>>
>> if (s[count] == ':') {
>> - nid = tmp;
>> - if (nid < 0 || nid >= MAX_NUMNODES)
>> + if (tmp < 0 || tmp >= MAX_NUMNODES)
>
> Here tmp is unsigned, no need to check if less than 0.
Thanks!
I shuffled the code a bit and missed this point. Actually, this routine
cmdline_parse_hugetlb_cma has the same issue you addressed in [1]. I did not
see that until now. It is fixed with this change.
I will send a v2 with:
- Remove check for unsigned tmp < 0
- Add a note in commit log that this also addresses an overflow truncation
issue in the assignement of an unsigned long to int.
[1] https://lore.kernel.org/linux-mm/20220209134018.8242-1-liuyuntao10@xxxxxxxxxx/
--
Mike Kravetz
