linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Muhammad Usama Anjum <Usama.Anjum@collabora.com>
To: Dan Carpenter <dan.carpenter@linaro.org>, linux-mm@kvack.org
Cc: Usama.Anjum@collabora.com, linux-fsdevel@vger.kernel.org,
	Kees Cook <keescook@chromium.org>
Subject: Re: [bug report] fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs
Date: Thu, 12 Sep 2024 14:34:54 +0500	[thread overview]
Message-ID: <d3db84fc-c107-423d-9f02-3cae0217b576@collabora.com> (raw)
In-Reply-To: <b33db5d3-2407-4d25-a516-f0fd8d74a827@collabora.com>

On 9/12/24 11:36 AM, Muhammad Usama Anjum wrote:
> Hi Dan,
> 
> Thank you for reporting.
I've debugged more and found out that no changes are required as
access_ok() already deals well with the overflows. I've tested the
corner cases on x86_64 and there are no issue found.

I'll add more test cases in the selftest for this ioctl. Please share
your thoughts if I may have missed something.

> 
> On 9/11/24 3:21 PM, Dan Carpenter wrote:
>> Hello Muhammad Usama Anjum,
>>
>> Commit 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and
>> optionally clear info about PTEs") from Aug 21, 2023 (linux-next),
>> leads to the following Smatch static checker warning:
>>
>> 	fs/proc/task_mmu.c:2664 pagemap_scan_get_args()
>> 	warn: potential user controlled sizeof overflow 'arg->vec_len * 24' '0-u64max * 24' type='ullong'
>>
>> fs/proc/task_mmu.c
>>     2637 static int pagemap_scan_get_args(struct pm_scan_arg *arg,
>>     2638                                  unsigned long uarg)
>>     2639 {
>>     2640         if (copy_from_user(arg, (void __user *)uarg, sizeof(*arg)))
>>
>> arg comes from the user
>>
>>     2641                 return -EFAULT;
>>     2642 
>>     2643         if (arg->size != sizeof(struct pm_scan_arg))
>>     2644                 return -EINVAL;
>>     2645 
>>     2646         /* Validate requested features */
>>     2647         if (arg->flags & ~PM_SCAN_FLAGS)
>>     2648                 return -EINVAL;
>>     2649         if ((arg->category_inverted | arg->category_mask |
>>     2650              arg->category_anyof_mask | arg->return_mask) & ~PM_SCAN_CATEGORIES)
>>     2651                 return -EINVAL;
>>     2652 
>>     2653         arg->start = untagged_addr((unsigned long)arg->start);
>>     2654         arg->end = untagged_addr((unsigned long)arg->end);
>>     2655         arg->vec = untagged_addr((unsigned long)arg->vec);
>>     2656 
>>     2657         /* Validate memory pointers */
>>     2658         if (!IS_ALIGNED(arg->start, PAGE_SIZE))
>>     2659                 return -EINVAL;
>>
>> We should probably check ->end here as well.
>>
>>     2660         if (!access_ok((void __user *)(long)arg->start, arg->end - arg->start))
> I'll add check to verify that end is equal or greater than start.
> 
>>
>> Otherwise we're checking access_ok() and then making ->end larger.  Maybe move
>> the arg->end = ALIGN(arg->end, PAGE_SIZE) before the access_ok() check?
>>
>>     2661                 return -EFAULT;
>>     2662         if (!arg->vec && arg->vec_len)
>>     2663                 return -EINVAL;
>> --> 2664         if (arg->vec && !access_ok((void __user *)(long)arg->vec,
>>     2665                               arg->vec_len * sizeof(struct page_region)))
>>
>> This "arg->vec_len * sizeof(struct page_region)" multiply could have an integer
>> overflow.
> I'll check for overflow before calling access_ok().
> 
>>
>> arg->vec_len is a u64 so size_add() won't work on a 32bit system.  I wonder if
>> size_add() should check for sizes larger than SIZE_MAX?
>>
>>     2666                 return -EFAULT;
>>     2667 
>>     2668         /* Fixup default values */
>>     2669         arg->end = ALIGN(arg->end, PAGE_SIZE);
>>     2670         arg->walk_end = 0;
>>     2671         if (!arg->max_pages)
>>     2672                 arg->max_pages = ULONG_MAX;
>>     2673 
>>     2674         return 0;
>>     2675 }
> I'll send fix soon.
> 
>>
>> regards,
>> dan carpenter
> 

-- 
BR,
Muhammad Usama Anjum



       reply	other threads:[~2024-09-12  9:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3a4e2a3e-b395-41e6-807d-0e6ad8722c7d@stanley.mountain>
     [not found] ` <b33db5d3-2407-4d25-a516-f0fd8d74a827@collabora.com>
2024-09-12  9:34   ` Muhammad Usama Anjum [this message]
2024-09-12 10:06     ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3db84fc-c107-423d-9f02-3cae0217b576@collabora.com \
    --to=usama.anjum@collabora.com \
    --cc=dan.carpenter@linaro.org \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox