From nobody Fri Oct 2 04:27:22 2026 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 181AA3E5A27 for ; Wed, 5 Aug 2026 08:01:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785916914; cv=none; b=huA0sVtryqppLL44Nb1gHXks2l+Q2HvEb77NARzuN7f4KyZDwa4l5Nn7Zf5W6V+SSEGlxvJSPojUcLbQIOeWNIYN8U5DR7xGHwHIQpbrQjJS36XWPWnBrIx5f1lJuhEkz7y17hlLxAI/vtfuZbDLzFYhBJhLOTQ2pFPbfnJea4M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785916914; c=relaxed/simple; bh=MlBqrOpt3rgDIGyH2ULIv4blD/fJqwd8tkI7/IUhkCI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=QHabfZ7mL96RFwU4Wj4UJrlGY1G1SK+yUOdlVEewp6kY2ICYVukl3041Z/xk8uhChdjBPSfySNWO2TKOjvbnhY6JjOtGyI2ydqZMXhNe9G3ELgE+3MD8gN3OQHbBX2VWk4hFFy17SRnGwycH6rqA5G+MW0bi1jVM0yHv4rn2oVI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=xbow.com; spf=pass smtp.mailfrom=xbow.com; dkim=pass (2048-bit key) header.d=xbow.com header.i=@xbow.com header.b=XMzaM2ql; arc=none smtp.client-ip=209.85.216.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=xbow.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=xbow.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=xbow.com header.i=@xbow.com header.b="XMzaM2ql" Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-3810c5d691bso561105a91.1 for ; Wed, 05 Aug 2026 01:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xbow.com; s=google; t=1785916912; x=1786521712; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=AUz5eQQY4ZXKNBZLMrPCzNtvBb314GGu8HHfd2z4ufg=; b=XMzaM2qlcdbKcysD6LMDSGvb1LChPkEwI/a6X6E3NOxCRX8DJ7tm/FFIA5hvGDccTT XOKbYAWxnwd3axUvarSkbbixqD6V776GzqlCDcHJ6Efk7C+LqcC3u4QfflNH+p87Roib WKED6Dh+gczkBU0IpUjXHHbAcuBUem/IUiFsbJZhRQOjNULft47zwBWzaqoBGhS9I2aG 3sp31CuUOlb4i0gL0N52y00HFrOrLcky/ylfnoU78G8hv7+CtjQ13ctAC4mwmVupy29m zCpZFKa1LtP/it3epRUFlYvNOsVzFKKgEsFcouHWVhK8KhZDyxCu8cJW6QPyilpmw3Z1 PVvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785916912; x=1786521712; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=AUz5eQQY4ZXKNBZLMrPCzNtvBb314GGu8HHfd2z4ufg=; b=mrbrsReq23eEI9rZw1fq43rc1iZKtkPxqQg47cpOhPtGr7hLWGbvCMUqcZFrCAJl9I 5DSVufPh8SwC9RUeoX6NgJjFLBoCi2ZadaJjQnJhjRnz4M2Vzoo1NYd2HSR9HtKsRmlM bRHP49paoIIaixALQCbGWXpvJccRVuxBlxC08SXNb76JENZoLBxmiBcra+3G15H9eR4+ /Lyk0zKcJ78P6KBB4VkQDJcJ55W7nt8xZfdCo8Xw7RbRUVQxQTYlfJJOwC88hzHgmzig Bz5xBqnG8Gl2Za8aJbWalSyhq0eW5vd2yOH6sfJE1+nb6Imfbycr4kZ0fJgmW+0TmoJb JM5w== X-Forwarded-Encrypted: i=1; AHgh+Rq4Ogi4vSOGNcf/Y9u/gL/zU522mSOwmw/HHDovNsDSyv59GRjXsSKPzf9eC9zW1KS69k5+7s0BymUZOMQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyBYIe6UZ4QQhDAFRxBCclFU40KxPPabV4fx3ctpactfKqB5bMs m8xtWWoEUBU0Cy9feNiF6AVKP5iwc1g8aHegnc/4ea8hZ8CFzQjxeBRkFQRWWwqt6QU= X-Gm-Gg: AR+sD10M+DNTc3UItJuaCrmLW9bPZCUZVBYxJn2rOJ5JKCuYPKWzwS2fu1sHsuFQ8jy Xms611Y7RPlTVEzjwOVnyqJRN3C80F5C3A95ESZAWgRki1mpJEunXPeSz+mlA74C6iq5j5S6uAn uSXiY5sXpdQ7Eq4YStG32m8OmoQmUc/uJvsKWG/svL/aXt3S0VV61FbBKocbD1Ge1I7UFTaI7Wr W2d308rGJB+01PtcgbxdAWicFI69JSQ0a1CPnWgV4vFHqGZIOWNWnWB6TIJA9iQXLnpdAxDVd3H oTMjayUih1qX1lQVSiDXttKY8BaxoVOFSB+Jvyitm6yqNoXFY0XaUeUpq1dyISxqRFRrWHn9+Ub ygoLwbzKa4d6jtxJHt3F+OssUQY59P4O2stPS5lShFkGOZGQHD1rxylG/+f1z1A+yHg0NHe44oQ 0dQx8pf8SKfIZ9n8b4HRarS9FgKQDwrgNxRmC6vFEsuN/CxM9NC5h8suesjSGtUgbZM7hChPjNe Fngl7MA9xmb119TgJ1CllFDn+jF X-Received: by 2002:a17:90a:ec8b:b0:38f:aab1:5148 with SMTP id 98e67ed59e1d1-3903c5d313bmr5059257a91.13.1785916912122; Wed, 05 Aug 2026 01:01:52 -0700 (PDT) Received: from Mac.lan ([125.128.148.126]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38febfdae62sm3922263a91.1.2026.08.05.01.01.49 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 05 Aug 2026 01:01:51 -0700 (PDT) From: Baul Lee To: maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, federico.kirschbaum@xbow.com, stable@vger.kernel.org, Baul Lee Subject: [PATCH] drm/gem-dma: bound the mmap against the object size Date: Wed, 5 Aug 2026 17:01:47 +0900 Message-ID: <20260805080147.12564-1-baul.lee@xbow.com> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" drm_gem_dma_mmap() passes the caller's request, not the object, as the size of the buffer being mapped: ret =3D dma_mmap_wc(drm_dev_dma_dev(dma_obj->base.dev), vma, dma_obj->vaddr, dma_obj->dma_addr, vma->vm_end - vma->vm_start); dma_direct_mmap() derives its page count from that size, so count and user_count are the same number and the bounds test degenerates into "vm_pgoff must be zero": unsigned long user_count =3D vma_pages(vma); unsigned long count =3D PAGE_ALIGN(size) >> PAGE_SHIFT; ... if (vma->vm_pgoff >=3D count || user_count > count - vma->vm_pgoff) return -ENXIO; remap_pfn_range() then installs writable PTEs for every frame the caller asked for, starting at the object and running past its end. On the DRM node that is unreachable: drm_gem_mmap_obj() rejects a VMA larger than the object before the object's mmap function runs. The fbdev emulation does not go through it. drm_fbdev_dma_fb_mmap() calls drm_gem_prime_mmap(), which invokes obj->funcs->mmap() directly, so /dev/fb0 accepts a length that /dev/dri/card0 refuses for the same object. The framebuffer is contiguous CMA inside system DRAM, so the excess mapping covers kernel-owned RAM, readable and writable, at an offset the caller picks. On arm64 a 1 GiB mapping of an 8294400-byte framebuffer object was accepted, and writes through it landed in the private memory of another unprivileged process. Nothing is logged: every access comes from userspace through a PTE the kernel installed. open() and mmap() on /dev/fb0 are enough, so any member of group video reaches it. Pass the object size to the DMA layer, which makes the dma_direct_mmap() test meaningful, and check the VMA length the way drm_gem_mmap_obj() does so both nodes reject the same request. Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA = helpers") Cc: stable@vger.kernel.org Signed-off-by: Baul Lee --- drivers/gpu/drm/drm_gem_dma_helper.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c b/drivers/gpu/drm/drm_gem= _dma_helper.c --- a/drivers/gpu/drm/drm_gem_dma_helper.c +++ b/drivers/gpu/drm/drm_gem_dma_helper.c @@ -531,6 +531,9 @@ int drm_gem_dma_mmap(struct drm_gem_dma_object *dma_obj= , struct vm_area_struct * struct drm_gem_object *obj =3D &dma_obj->base; int ret; + if (obj->size < vma->vm_end - vma->vm_start) + return -EINVAL; + /* * Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the * vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map @@ -543,12 +546,12 @@ int drm_gem_dma_mmap(struct drm_gem_dma_object *dma_o= bj, struct vm_area_struct * vma->vm_page_prot =3D vm_get_page_prot(vma->vm_flags); ret =3D dma_mmap_pages(drm_dev_dma_dev(dma_obj->base.dev), - vma, vma->vm_end - vma->vm_start, + vma, obj->size, virt_to_page(dma_obj->vaddr)); } else { ret =3D dma_mmap_wc(drm_dev_dma_dev(dma_obj->base.dev), vma, dma_obj->vaddr, dma_obj->dma_addr, - vma->vm_end - vma->vm_start); + obj->size); } if (ret) drm_gem_vm_close(vma); --=20 2.50.1 (Apple Git-155)