From nobody Thu Sep 3 07:03:25 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1788184006; cv=none; d=zohomail.com; s=zohoarc; b=TEaTQxNCgmloUDS5GMmbGalD98zx9l8+G9tIRxRT/3u4VxAhYt4NxNY+gNase+mhygT7r1LI+WcQK6mCYzZUbxpl/LfIY1GFmPdDF33IhyHe9XCzJkx+eN939qlhNApstBBpTlM2refnXcxYhvNZvC/8YXGV3u1vpYnDCSlXVJA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1788184006; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=VuuTfQsSlsnIRKrUr/mDOL2bAkwlXnRRMmPO/GFFYPA=; b=dl4PgrA5a7hVkL9HnjWR1rNlXpNl1BVyt0YRIuoWQK/6vii9VGoDfuEI4FNkpi1WmtEekfeJAlpc9arYFjFw8xpG5dvtQw/Y6cLE0xo2uYA/ZVDyU4ZAII+wG4CA5tO0wAiF9BtT+a9e4eVcXS9dDX67AjZZigT3BXG8/S+MfRk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1788184006351987.770444827133; Mon, 31 Aug 2026 06:46:46 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1404069.1638005 (Exim 4.92) (envelope-from ) id 1x12L6-0001ii-QT; Mon, 31 Aug 2026 13:46:20 +0000 Received: by outflank-mailman (output) from mailman id 1404069.1638005; Mon, 31 Aug 2026 13:46:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x12L6-0001ib-NY; Mon, 31 Aug 2026 13:46:20 +0000 Received: by outflank-mailman (input) for mailman id 1404069; Mon, 31 Aug 2026 13:46:20 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1x12L6-0001iV-1F for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 13:46:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1x12L4-000k2h-4b for xen-devel@lists.xenproject.org; Mon, 31 Aug 2026 15:46:18 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a95859a-2eae-0a2a0a5409dd-0a2a45059c0a-44 for ; Mon, 31 Aug 2026 15:46:18 +0200 Received: from [172.105.4.254] (helo=tor.source.kernel.org) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a9585a8-4cb1-0a2a45050019-ac6904feb42e-3 for ; Mon, 31 Aug 2026 15:46:17 +0200 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 7FABB60207; Mon, 31 Aug 2026 13:46:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CE281F00A3E; Mon, 31 Aug 2026 13:46:14 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=k20260515 header.d=kernel.org header.i="@kernel.org" header.h="From:To:Cc:Subject:Date:In-Reply-To:References" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788183975; bh=VuuTfQsSlsnIRKrUr/mDOL2bAkwlXnRRMmPO/GFFYPA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=iuQOydXpKQt7a1jrYnXvxz7aQoIBCAIFNAv8EO+fBl9su81MHY8w4LofBu/My120O HfxrnjWbBjI9EIMnOnAbhove+XB7itONKmPObfJ8BBqywYenmcucJkIlYPVTh/0z0A ps1dPvhLbgt3Owl/Pc24DurbtbBTtexTy9LRjri94Iw+AGgVCCxauPZA0qOLCCTw5p 20KwhhSloo5K6hqhVASUKB35Mb4EJl9l/olv96/HlXBA4Qr8cFmkozXPAezRsJqnw4 w5rg67QthsQRBYGHGuYJL5oF3jZtmzLZPd/iHKocBv6uL5OJjV7cCUos1poqzORyKs 10sUmsRrufMyw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Yousef Alhouseen , Juergen Gross , Sasha Levin , sstabellini@kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-5.10] xen/gntalloc: validate grant count before allocation Date: Mon, 31 Aug 2026 09:27:23 -0400 Message-ID: <20260831133314.4125787-415-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260831133314.4125787-1-sashal@kernel.org> References: <20260831133314.4125787-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.48 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1788183977-734BC2A1-36D7AF9E/0/0 X-purgate-type: clean X-purgate-size: 15461 X-ZohoMail-DKIM: pass (identity @kernel.org) X-ZM-MESSAGEID: 1788184009784154100 From: Yousef Alhouseen [ Upstream commit 2299822f3f466b5dcad2377bf63986199f881a6b ] gntalloc_ioctl_alloc() allocates the grant-id array before checking whether the requested count fits within the global grant limit. Counts above that limit cannot succeed, so reject them before the user-controlled allocation reaches kcalloc(). Use a subtraction-based check while holding gref_mutex so adding the requested count cannot wrap. Also cast the count before advancing the per-file index so the page-size multiplication is performed in 64-bit arithmetic. Signed-off-by: Yousef Alhouseen Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Message-ID: <20260626223805.43781-3-alhouseenyousef@gmail.com> Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Phase 1: Commit Message Forensics **Step 1.1 =E2=80=94 Subject line** Record: `[xen/gntalloc] [validate] validate grant count before allocation` =E2=80=94 ioctl input validation and overflow-safety fix in the= Xen grant allocator. **Step 1.2 =E2=80=94 Tags** Record: - `Signed-off-by: Yousef Alhouseen ` (author) - `Reviewed-by: Juergen Gross ` (Xen maintainer =E2=80=94 strong quality signal) - `Signed-off-by: Juergen Gross ` - `Message-ID: <20260626223805.43781-3-alhouseenyousef@gmail.com>` (patch 2/2 of v2 series) - No `Fixes:`, `Reported-by:`, `Link:`, `Cc: stable@vger.kernel.org`, or `Tested-by:` tags **Step 1.3 =E2=80=94 Body analysis** Record: - **Bug:** `gntalloc_ioctl_alloc()` calls `kcalloc(op.count, ...)` before verifying `op.count` against the global grant limit. - **Symptom:** User-controlled counts above the limit still reach kernel allocation; limit enforcement uses addition with mixed signed/unsigned types that can wrap; `priv->index` advance uses 32-bit multiply. - **Failure modes:** Unnecessary kernel allocations (memory pressure/DoS), potential limit-check bypass via wrap, corrupted per- file mmap index. - **Root cause:** Validation ordering and unsafe arithmetic on user- supplied `op.count` (`__u32`). **Step 1.4 =E2=80=94 Hidden bug fix?** Record: **Yes.** Although the subject says "validate," this is a real bug fix: premature allocation, integer-overflow-prone limit check, and 32-bit multiply before 64-bit assignment. --- ## Phase 2: Diff Analysis **Step 2.1 =E2=80=94 Inventory** Record: - 1 file: `drivers/xen/gntalloc.c` (+11 / -2 net) - Function modified: `gntalloc_ioctl_alloc()` - Scope: single-file, surgical ioctl-path fix **Step 2.2 =E2=80=94 Code flow per hunk** | Hunk | Before | After | |------|--------|-------| | Early check | `kcalloc()` immediately after `copy_from_user()` | Snapshot `limit` with `READ_ONCE()`, reject `op.count > limit` with `-ENOSPC` before any allocation | | Locked limit check | `gref_size + op.count > limit` | Subtraction: `gref_size > limit_snapshot \|\| op.count > limit_snapshot - gref_size` under `gref_mutex` | | Index advance | `priv->index +=3D op.count * PAGE_SIZE` (32-bit multiply) | `priv->index +=3D (uint64_t)op.count * PAGE_SIZE` | Record: Normal ioctl path and error paths affected; early rejection avoids `kcalloc`/`kfree` on doomed requests. **Step 2.3 =E2=80=94 Bug mechanism** Record: - **Category:** Input validation + integer overflow / type-safety - **Mechanism 1:** User `count` drives `kcalloc()` before limit enforcement =E2=86=92 kmem pressure DoS on `/dev/xen/gntalloc` - **Mechanism 2:** `gref_size + op.count > limit` mixes `int` counters with `uint32_t` count; addition can wrap, potentially bypassing limit and reaching `add_grefs()`'s `for (i =3D 0; i < op->count; i++)` loop - **Mechanism 3:** `op.count * PAGE_SIZE` computed in 32-bit arithmetic before widening to `uint64_t priv->index` **Step 2.4 =E2=80=94 Fix quality** Record: Minimal, obviously correct, no API changes. Early check is cheap. Subtraction check is standard overflow-safe idiom. `READ_ONCE(limit)` snapshots admin-tunable limit. Regression risk: **low** =E2=80=94 only tightens validation; legitimate allocations within l= imit unchanged. --- ## Phase 3: Git History Investigation **Step 3.1 =E2=80=94 Blame** Record: Buggy lines in `gntalloc_ioctl_alloc()` trace to `5d324e5159d9e` in this shallow checkout (file unchanged since tree root). The ioctl allocation pattern is long-standing driver code, not a recent regression. **Step 3.2 =E2=80=94 Fixes: tag** Record: Not applicable =E2=80=94 no `Fixes:` tag present. **Step 3.3 =E2=80=94 Related file history** Record: Shallow tree shows only merge commit touching `drivers/xen/gntalloc.c`. IOCTL path with `kcalloc`-before-limit pattern is present at HEAD. **Step 3.4 =E2=80=94 Author context** Record: Yousef Alhouseen submitted the v2 series. Juergen Gross (active Xen maintainer; recent xen commits in tree include `xen/privcmd` security fixes) reviewed and signed off. **Step 3.5 =E2=80=94 Dependencies** Record: **Series dependency identified.** Cover letter ([openwall v2 0/2](https://lists.openwall.net/linux-kernel/2026/06/26/2112)) states patch 1/2 (`xen/gntalloc: make grant counters unsigned`) is a prerequisite for overflow-safe unsigned arithmetic. **This commit (2/2) applies cleanly standalone** to the current tree (`git apply --check` succeeded). Patch 1/2 is a 3-line companion change (`int` =E2=86=92 `unsign= ed int` for `limit`/`gref_size`, `module_param(limit, uint, ...)`). Not a hard blocker for backporting this patch, but both should ideally ship together for a complete fix. --- ## Phase 4: Mailing List and External Research **Step 4.1 =E2=80=94 Original discussion** Record: `b4 dig -c ` unavailable (commit not in local tree). Found via openwall: - Cover: https://lists.openwall.net/linux-kernel/2026/06/26/2112 - Patch 1/2: https://lists.openwall.net/linux-kernel/2026/06/26/2113 - Patch 2/2 (this commit): https://lists.openwall.net/linux- kernel/2026/06/26/2114 - v2 split unsigned-type changes into prerequisite per maintainer feedback **Step 4.2 =E2=80=94 Reviewers** Record: To: Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko; Cc: xen-devel, linux-kernel. Juergen Gross reviewed. **Step 4.3 =E2=80=94 Bug report** Record: No external bug report or syzbot link. Issue identified by code review / proactive hardening. **Step 4.4 =E2=80=94 Series context** Record: 2-patch v2 series, same file. Patch 1 prepares unsigned counters; patch 2 adds validation. Both are small and complementary. **Step 4.5 =E2=80=94 Stable list** Record: No stable-list discussion found. lore.kernel.org returned 403 (bot protection); openwall used instead. --- ## Phase 5: Code Semantic Analysis **Step 5.1 =E2=80=94 Key functions** Record: `gntalloc_ioctl_alloc()` (modified); related: `add_grefs()`, `do_cleanup()`. **Step 5.2 =E2=80=94 Callers** Record: `gntalloc_ioctl()` =E2=86=92 `case IOCTL_GNTALLOC_ALLOC_GREF` =E2= =86=92 `gntalloc_ioctl_alloc()`. Reachable from userspace via `ioctl()` on `/dev/xen/gntalloc` (`miscdevice`, name `"xen/gntalloc"`). **Step 5.3 =E2=80=94 Callees** Record: `copy_from_user`, `kcalloc`, `mutex_lock/unlock`, `do_cleanup`, `add_grefs` (allocates pages, grants foreign access in a loop over `op->count`), `copy_to_user`, `kfree`. **Step 5.4 =E2=80=94 Reachability** Record: Userspace ioctl on Xen systems with `CONFIG_XEN_GRANT_DEV_ALLOC`. Kconfig: "Allows userspace processes to create pages with access granted to other domains." Impact surface: Xen dom0 / Xen PV frontends using grant allocation =E2=80=94 not universal, but ioctl is explicitly user-facing. **Step 5.5 =E2=80=94 Similar patterns** Record: No other instances of this exact bug pattern in `gntalloc.c`. The `add_grefs()` loop makes a bypassed limit check especially dangerous (unbounded iteration + per-page allocations). --- ## Phase 6: Cross-Reference Against Local Tree (6.18.44) **Step 6.1 =E2=80=94 Buggy code present?** Record: **Yes.** Local tree is `v6.18.44-1-g2736c32da98b9` / `6.18.44`. At HEAD, `gntalloc_ioctl_alloc()` still does `kcalloc()` before limit check, uses `gref_size + op.count > limit`, and `priv->index +=3D op.count * PAGE_SIZE`. `limit`/`gref_size` are `static int`. **Step 6.2 =E2=80=94 Backport complications** Record: **Clean apply** =E2=80=94 `git apply --check` on the provided diff succeeded with no conflicts. **Step 6.3 =E2=80=94 Related fixes already present?** Record: No =E2=80=94 `git log --grep=3D"gntalloc"` and `--grep=3D"validate = grant count"` returned nothing. Fix not yet in this tree. --- ## Phase 7: Subsystem and Maintainer Context **Step 7.1 =E2=80=94 Subsystem** Record: `drivers/xen/` =E2=80=94 Xen grant-table userspace interface. Criticality: **IMPORTANT** for Xen deployments (dom0, paravirt frontends); **PERIPHERAL** relative to all Linux users. **Step 7.2 =E2=80=94 Activity** Record: Xen subsystem actively maintained; recent security fixes in related xen drivers (`privcmd`, `sys-hypervisor`) in this tree. --- ## Phase 8: Impact and Risk Assessment **Step 8.1 =E2=80=94 Who is affected** Record: Xen systems with `CONFIG_XEN_GRANT_DEV_ALLOC` (default `m`), users/processes that can open `/dev/xen/gntalloc` and issue `IOCTL_GNTALLOC_ALLOC_GREF`. **Step 8.2 =E2=80=94 Trigger conditions** Record: - **Common:** `op.count > limit` (default 1024) =E2=86=92 unnecessary `kcal= loc` before `-ENOSPC`; repeatable for memory pressure - **Less common:** Large `limit` module parameter + crafted counts =E2=86= =92 addition wrap bypassing limit =E2=86=92 massive `add_grefs()` loop - **Less common:** Large `op.count` with raised limit =E2=86=92 32-bit `op.= count * PAGE_SIZE` wrap corrupting `priv->index` - Unprivileged users need device access; still a valid hardening for any caller with ioctl access **Step 8.3 =E2=80=94 Failure severity** Record: - Memory pressure / DoS from premature allocations: **MEDIUM-HIGH** - Limit bypass =E2=86=92 huge grant allocation loop: **CRITICAL** (hang/OOM= ) if triggerable - Index corruption: **HIGH** (broken mmap offsets / grant bookkeeping) - Overall: **HIGH** for affected Xen configurations **Step 8.4 =E2=80=94 Risk vs benefit** Record: - **Benefit:** HIGH for Xen users =E2=80=94 closes validation gap on user-f= acing ioctl - **Risk:** LOW =E2=80=94 11 lines, no behavior change for valid requests w= ithin limit - **Ratio:** Strong benefit, low risk --- ## Phase 9: Final Synthesis **Step 9.1 =E2=80=94 Evidence summary** **FOR backport:** - Fixes real bugs (premature user-sized allocation, overflow-prone limit check, 32-bit multiply) - Small, surgical, maintainer-reviewed - Applies cleanly to 6.18.44 - Buggy code confirmed present in this tree - User-facing ioctl path on Xen systems - Companion patch 1/2 is tiny and should accompany for complete unsigned-counter hardening **AGAINST backport:** - Xen-specific; not all stable users run Xen - No syzbot/user crash report (proactive fix) - Ideally paired with patch 1/2 for full unsigned arithmetic story (minor concern, not a blocker) **Unresolved:** Whether reviewers explicitly nominated for stable (no thread replies fetched beyond cover/patch text). **Step 9.2 =E2=80=94 Stable rules checklist** 1. Obviously correct and tested? **PASS** =E2=80=94 logic is straightforwar= d; reviewed by Juergen Gross; no `Tested-by` 2. Fixes real bug affecting users? **PASS** =E2=80=94 ioctl validation / overflow issues on Xen grant allocator 3. Important issue? **PASS** =E2=80=94 DoS, potential limit bypass, index corruption (HIGH severity on Xen) 4. Small and contained? **PASS** =E2=80=94 1 file, ~13 lines changed 5. No new features/APIs? **PASS** =E2=80=94 validation only 6. Can apply to local tree? **PASS** =E2=80=94 verified clean apply **Step 9.3 =E2=80=94 Exception category** Record: None (standard bug fix, not device ID/quirk/docs/build). **Step 9.4 =E2=80=94 Decision rationale** This commit should be backported to the local **6.18.44** stable tree. The buggy ioctl ordering and arithmetic are present, the fix is minimal and maintainer-reviewed, and the failure modes (kmem pressure, limit bypass, index corruption) are meaningful on Xen systems. Backport patch 1/2 (`make grant counters unsigned`) alongside this commit for the complete v2 series. --- ## Verification - [Phase 1] Parsed subject, tags, body from provided commit message - [Phase 1] Identified patch as 2/2 via Message-ID `43781-3` - [Phase 2] Read current `gntalloc_ioctl_alloc()` at HEAD =E2=80=94 confirm= ed buggy ordering - [Phase 2] Verified `limit`/`gref_size` are `static int`, `op.count` is `__u32`, `priv->index` is `uint64_t` - [Phase 2] Verified `kcalloc` uses `check_mul_overflow` in `include/linux/slab.h` - [Phase 3] `git blame -L 283,302 drivers/xen/gntalloc.c` =E2=80=94 lines f= rom `5d324e5159d9e` - [Phase 3] `git log --oneline -20 -- drivers/xen/gntalloc.c` =E2=80=94 sha= llow history - [Phase 3] `git log --grep` for gntalloc/validate =E2=80=94 no existing fi= x in tree - [Phase 4] `b4 dig -c 3218686be45b8` =E2=80=94 no result (commit not in tr= ee) - [Phase 4] Fetched openwall cover + patches 1/2 and 2/2 =E2=80=94 confirme= d v2 series and prerequisite note - [Phase 4] lore.kernel.org =E2=80=94 403 Forbidden (unverified for reviewer stable nominations) - [Phase 5] Traced call chain: `gntalloc_ioctl` =E2=86=92 `gntalloc_ioctl_a= lloc` - [Phase 5] Confirmed miscdevice `"xen/gntalloc"` registration - [Phase 5] Read `add_grefs()` =E2=80=94 loops `op->count` times with page = alloc + grant setup - [Phase 6] `git describe HEAD` =E2=86=92 `v6.18.44-1-g2736c32da98b9`; `make kernelversion` =E2=86=92 `6.18.44` - [Phase 6] `git apply --check` on provided diff =E2=80=94 **clean apply** - [Phase 6] Confirmed pre-fix code via `git show HEAD:drivers/xen/gntalloc.c` - [Phase 7] Read `drivers/xen/Kconfig` `XEN_GRANT_DEV_ALLOC` =E2=80=94 userspace-facing, default `m` - [Phase 8] Assessed severity from code paths (not from unverified crash reports) **YES** drivers/xen/gntalloc.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/xen/gntalloc.c b/drivers/xen/gntalloc.c index f93f73ecefeee..462f67dc32751 100644 --- a/drivers/xen/gntalloc.c +++ b/drivers/xen/gntalloc.c @@ -272,6 +272,7 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file_p= rivate_data *priv, int rc =3D 0; struct ioctl_gntalloc_alloc_gref op; uint32_t *gref_ids; + unsigned int limit_snapshot; =20 pr_debug("%s: priv %p\n", __func__, priv); =20 @@ -280,6 +281,12 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file_= private_data *priv, goto out; } =20 + limit_snapshot =3D READ_ONCE(limit); + if (op.count > limit_snapshot) { + rc =3D -ENOSPC; + goto out; + } + gref_ids =3D kcalloc(op.count, sizeof(gref_ids[0]), GFP_KERNEL); if (!gref_ids) { rc =3D -ENOMEM; @@ -292,14 +299,16 @@ static long gntalloc_ioctl_alloc(struct gntalloc_file= _private_data *priv, * are about to enforce, removing them here is a good idea. */ do_cleanup(); - if (gref_size + op.count > limit) { + limit_snapshot =3D READ_ONCE(limit); + if (gref_size > limit_snapshot || + op.count > limit_snapshot - gref_size) { mutex_unlock(&gref_mutex); rc =3D -ENOSPC; goto out_free; } gref_size +=3D op.count; op.index =3D priv->index; - priv->index +=3D op.count * PAGE_SIZE; + priv->index +=3D (uint64_t)op.count * PAGE_SIZE; mutex_unlock(&gref_mutex); =20 rc =3D add_grefs(&op, gref_ids, priv); --=20 2.53.0