From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: dma-buf: add DMA_BUF_IOCTL_DERIVE for reduced-permission aliases Date: Mon, 25 May 2026 20:27:32 +1000 Message-ID: In-Reply-To: <20260521-dmabuf-limit-access-v1-0-26c01e27365a@redhat.com> References: <20260521-dmabuf-limit-access-v1-0-26c01e27365a@redhat.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: dma-buf: add DMA_BUF_IOCTL_DERIVE for reduced-permission aliases Author: Albert Esteve Patches: 7 Reviewed: 2026-05-25T20:27:32.725080 --- This series adds `DMA_BUF_IOCTL_DERIVE`, a mechanism to create a new file d= escriptor for an existing dma-buf with a subset of the caller's permissions= . The use case (handing read-only views to less-privileged consumers) is we= ll-motivated and the cover letter does a good job explaining why existing a= pproaches (dup, /proc/self/fd, re-export) don't work. The overall design =E2=80=94 cloning the file with `alloc_file_clone`, shar= ing the same `struct dma_buf` / `dma_resv`, and adding a targeted mmap writ= e check =E2=80=94 is reasonable. The refcount management via `get_dma_buf` = / `dma_buf_put` and the move of `__dma_buf_list_del` to dentry release are = sound. However, there is a **security bug** in the permission escalation check: `O= _WRONLY` is not blocked when deriving from an `O_RDONLY` fd, which is a pri= vilege escalation. There are also a few design gaps worth discussing (DMA a= ccess, sync ioctl, write-only interactions). --- --- Generated by Claude Code Patch Reviewer