All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Linke Li <lilinke99@foxmail.com>, linux-mm@kvack.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
	mike.kravetz@oracle.com, muchun.song@linux.dev,
	nathan@kernel.org, ndesaulniers@google.com, trix@redhat.com,
	linux-kernel@vger.kernel.org, dan.carpenter@linaro.org,
	Linke Li <lilinke99@gmail.com>
Subject: Re: [PATCH v3] hugetlbfs: Fix integer overflow check in hugetlbfs_file_mmap()
Date: Fri, 21 Jul 2023 07:36:54 +0800	[thread overview]
Message-ID: <202307210737.HUPwpBdW-lkp@intel.com> (raw)
In-Reply-To: <tencent_C2D6865561F23A8141BB145149ACC682B408@qq.com>

Hi Linke,

kernel test robot noticed the following build warnings:

[auto build test WARNING on linus/master]
[also build test WARNING on v6.5-rc2 next-20230720]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Linke-Li/hugetlbfs-Fix-integer-overflow-check-in-hugetlbfs_file_mmap/20230720-225128
base:   linus/master
patch link:    https://lore.kernel.org/r/tencent_C2D6865561F23A8141BB145149ACC682B408%40qq.com
patch subject: [PATCH v3] hugetlbfs: Fix integer overflow check in hugetlbfs_file_mmap()
config: s390-randconfig-r024-20230720 (https://download.01.org/0day-ci/archive/20230721/202307210737.HUPwpBdW-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce: (https://download.01.org/0day-ci/archive/20230721/202307210737.HUPwpBdW-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202307210737.HUPwpBdW-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> fs/hugetlbfs/inode.c:157:25: warning: variable 'vma_len' is uninitialized when used here [-Wuninitialized]
     157 |         if (check_add_overflow(vma_len, (loff_t)vma->vm_pgoff << PAGE_SHIFT, &len))
         |                                ^~~~~~~
   include/linux/overflow.h:67:47: note: expanded from macro 'check_add_overflow'
      67 |         __must_check_overflow(__builtin_add_overflow(a, b, d))
         |                                                      ^
   fs/hugetlbfs/inode.c:123:21: note: initialize the variable 'vma_len' to silence this warning
     123 |         loff_t len, vma_len;
         |                            ^
         |                             = 0
   1 warning generated.


vim +/vma_len +157 fs/hugetlbfs/inode.c

   108	
   109	/*
   110	 * Mask used when checking the page offset value passed in via system
   111	 * calls.  This value will be converted to a loff_t which is signed.
   112	 * Therefore, we want to check the upper PAGE_SHIFT + 1 bits of the
   113	 * value.  The extra bit (- 1 in the shift value) is to take the sign
   114	 * bit into account.
   115	 */
   116	#define PGOFF_LOFFT_MAX \
   117		(((1UL << (PAGE_SHIFT + 1)) - 1) <<  (BITS_PER_LONG - (PAGE_SHIFT + 1)))
   118	
   119	static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma)
   120	{
   121		struct inode *inode = file_inode(file);
   122		struct hugetlbfs_inode_info *info = HUGETLBFS_I(inode);
   123		loff_t len, vma_len;
   124		int ret;
   125		struct hstate *h = hstate_file(file);
   126	
   127		/*
   128		 * vma address alignment (but not the pgoff alignment) has
   129		 * already been checked by prepare_hugepage_range.  If you add
   130		 * any error returns here, do so after setting VM_HUGETLB, so
   131		 * is_vm_hugetlb_page tests below unmap_region go the right
   132		 * way when do_mmap unwinds (may be important on powerpc
   133		 * and ia64).
   134		 */
   135		vm_flags_set(vma, VM_HUGETLB | VM_DONTEXPAND);
   136		vma->vm_ops = &hugetlb_vm_ops;
   137	
   138		ret = seal_check_future_write(info->seals, vma);
   139		if (ret)
   140			return ret;
   141	
   142		/*
   143		 * page based offset in vm_pgoff could be sufficiently large to
   144		 * overflow a loff_t when converted to byte offset.  This can
   145		 * only happen on architectures where sizeof(loff_t) ==
   146		 * sizeof(unsigned long).  So, only check in those instances.
   147		 */
   148		if (sizeof(unsigned long) == sizeof(loff_t)) {
   149			if (vma->vm_pgoff & PGOFF_LOFFT_MAX)
   150				return -EINVAL;
   151		}
   152	
   153		/* must be huge page aligned */
   154		if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT))
   155			return -EINVAL;
   156	
 > 157		if (check_add_overflow(vma_len, (loff_t)vma->vm_pgoff << PAGE_SHIFT, &len))
   158			return -EINVAL;
   159	
   160		inode_lock(inode);
   161		file_accessed(file);
   162	
   163		ret = -ENOMEM;
   164		if (!hugetlb_reserve_pages(inode,
   165					vma->vm_pgoff >> huge_page_order(h),
   166					len >> huge_page_shift(h), vma,
   167					vma->vm_flags))
   168			goto out;
   169	
   170		ret = 0;
   171		if (vma->vm_flags & VM_WRITE && inode->i_size < len)
   172			i_size_write(inode, len);
   173	out:
   174		inode_unlock(inode);
   175	
   176		return ret;
   177	}
   178	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  parent reply	other threads:[~2023-07-20 23:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20 14:49 [PATCH v3] hugetlbfs: Fix integer overflow check in hugetlbfs_file_mmap() Linke Li
2023-07-20 18:41 ` Mike Kravetz
2023-07-20 19:03 ` Nick Desaulniers
2023-07-20 23:36 ` kernel test robot [this message]
2023-07-24  3:47 ` Matthew Wilcox
2023-07-24 18:59   ` Mike Kravetz
2023-07-24  8:11 ` kernel test robot

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=202307210737.HUPwpBdW-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=dan.carpenter@linaro.org \
    --cc=lilinke99@foxmail.com \
    --cc=lilinke99@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=llvm@lists.linux.dev \
    --cc=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=trix@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.