From: Matthew Auld <matthew.auld@intel.com>
To: "Lin, Shuicheng" <shuicheng.lin@intel.com>,
"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe: Prevent BIT() overflow when handling invalid prefetch region
Date: Wed, 12 Nov 2025 17:02:07 +0000 [thread overview]
Message-ID: <09218055-ee5a-45c1-a816-157376b3af39@intel.com> (raw)
In-Reply-To: <DM4PR11MB5456E2B0A9E44FE1603FB117EACCA@DM4PR11MB5456.namprd11.prod.outlook.com>
On 12/11/2025 16:26, Lin, Shuicheng wrote:
> On Wed, Nov 12, 2025 2:24 AM Matthew Auld wrote:
>> On 12/11/2025 00:23, Shuicheng Lin wrote:
>>> If user provides a large value (such as 0x80) for parameter
>>> prefetch_mem_region_instance in vm_bind ioctl, it will cause
>>> BIT(prefetch_region) overflow as below:
>>> "
>>> ------------[ cut here ]------------
>>> UBSAN: shift-out-of-bounds in drivers/gpu/drm/xe/xe_vm.c:3414:7
>>> shift exponent 128 is too large for 64-bit type 'long unsigned int'
>>> CPU: 8 UID: 0 PID: 53120 Comm: xe_exec_system_ Tainted: G W
>> 6.18.0-rc1-lgci-xe-kernel+ #200 PREEMPT(voluntary)
>>> Tainted: [W]=WARN
>>> Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS
>> 0812 02/24/2023
>>> Call Trace:
>>> <TASK>
>>> dump_stack_lvl+0xa0/0xc0
>>> dump_stack+0x10/0x20
>>> ubsan_epilogue+0x9/0x40
>>> __ubsan_handle_shift_out_of_bounds+0x10e/0x170
>>> ? mutex_unlock+0x12/0x20
>>> xe_vm_bind_ioctl.cold+0x20/0x3c [xe]
>>> ...
>>> "
>>> Fix it by validating prefetch_region before the BIT() usage.
>>>
>>> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel
>>> GPUs")
>>
>> I think should be:
>>
>> Fixes: c1bb69a2e8e2 ("drm/xe/svm: Consult madvise preferred location in
>> prefetch")
>
> The UBSAN warning is for the BIT(), and this BIT() check exists since dd08ebf6c352.
> The c1bb69a2e8e2 is for "region_to_mem_type[prefetch_region]", which is truly
> an issue, but not the UBSAN complain about. So I prefer to use dd08ebf6c352.
> What is your idea about it? Thanks.
Oh, I see. Sorry for missing that. That is slightly annoying since we
will need to be backport this fix to older kernels, but this patch won't
apply cleanly. The s/region/prefetch_region/ is fairly recent.
In that case, I think we at least need to add:
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: <stable@vger.kernel.org> # v6.8+
So this doesn't fall through the cracks. Once this gets picked up for
older stable kernels you should get mail(s) for which kernels this patch
fails to cleanly apply on, and the mail itself will contain instructions
for how to send a patch. I think that should work?
>
>>
>> And also:
>>
>> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6478
>
> Let me add it. I didn't add it because I cannot open it.
> Maybe it is due to some permission.
>
>>
>>> Cc: Matthew Auld <matthew.auld@intel.com>
>>> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
>>
>> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
>>
>> An IGT that uses a too large prefetch_region would be good also.
>
> Let me implement it later.
>
> Shuicheng
>
>>
>>> ---
>>> drivers/gpu/drm/xe/xe_vm.c | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
>>> index 8fb5cc6a69ec..7cac646bdf1c 100644
>>> --- a/drivers/gpu/drm/xe/xe_vm.c
>>> +++ b/drivers/gpu/drm/xe/xe_vm.c
>>> @@ -3411,8 +3411,10 @@ static int vm_bind_ioctl_check_args(struct
>> xe_device *xe, struct xe_vm *vm,
>>> op == DRM_XE_VM_BIND_OP_PREFETCH) ||
>>> XE_IOCTL_DBG(xe, prefetch_region &&
>>> op != DRM_XE_VM_BIND_OP_PREFETCH) ||
>>> - XE_IOCTL_DBG(xe, (prefetch_region !=
>> DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC &&
>>> - !(BIT(prefetch_region) & xe-
>>> info.mem_region_mask))) ||
>>> + XE_IOCTL_DBG(xe, (prefetch_region !=
>> DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC &&
>>> + /* Guard against undefined shift in
>> BIT(prefetch_region) */
>>> + (prefetch_region >= (sizeof(xe-
>>> info.mem_region_mask) * 8) ||
>>> + !(BIT(prefetch_region) & xe-
>>> info.mem_region_mask)))) ||
>>> XE_IOCTL_DBG(xe, obj &&
>>> op == DRM_XE_VM_BIND_OP_UNMAP) ||
>>> XE_IOCTL_DBG(xe, (flags &
>>> DRM_XE_VM_BIND_FLAG_MADVISE_AUTORESET) &&
>
next prev parent reply other threads:[~2025-11-12 17:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 0:23 [PATCH] drm/xe: Prevent BIT() overflow when handling invalid prefetch region Shuicheng Lin
2025-11-12 0:32 ` ✓ CI.KUnit: success for " Patchwork
2025-11-12 1:25 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-12 7:59 ` ✗ Xe.CI.Full: failure " Patchwork
2025-11-12 10:24 ` [PATCH] " Matthew Auld
2025-11-12 16:26 ` Lin, Shuicheng
2025-11-12 17:02 ` Matthew Auld [this message]
2025-11-12 18:08 ` Lin, Shuicheng
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=09218055-ee5a-45c1-a816-157376b3af39@intel.com \
--to=matthew.auld@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=shuicheng.lin@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox