From nobody Sat Jun 13 06:26:24 2026 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.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 671E8325727 for ; Sat, 9 May 2026 06:58:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.208.50 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778309941; cv=pass; b=XyyA0OHpUYk23y7rx/gRZCq4Zqj4t8WLc26xabQRd+NvZSH/tsMsNFW57KNc6Igd5TMPqzdFosug0jygEU75bDPXOYgE6veGuDYwKEcYaCT9VwaExlRfWzj63nG/Yrz2d/k+0wc2TYch9BVEB5uO5huyJyqygcKfn2VNuyux9nI= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778309941; c=relaxed/simple; bh=Iesy03fy3D5hzUgxS6UMqe/aNPanV+wNGp+mdEaII4A=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=CnSQT1md3uyRq28twMoxSyRbG5lSBSH1hoFWh7BphTrRinnEGm3fovGh1Y3ZWOB+8Q+LSHZnxxl5N3mIrqo0hZ7+ERR0YqSYxxAqf0dCWQApqbIaFMmT0AXXWSMw+7rc7MEZOSy5jF1s+PQdQt7bjY4HOfD62/cbH7eX9gMy1R4= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SxvwGLS7; arc=pass smtp.client-ip=209.85.208.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SxvwGLS7" Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-67b7c77865dso4355054a12.2 for ; Fri, 08 May 2026 23:58:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778309938; cv=none; d=google.com; s=arc-20240605; b=TbpSIijYlcyRMMScpkNZ/CrB8cWxJ0xmEohrZYj7Z7S+9MXE4xPEXj6v5QsEDKMdD7 3Kzy88rC7dZFMy9RmkHguFZiGnE9p2ZX1cjxBsuAEUY5ofhbsPPcoI4rLpFve8tfrwvZ Pvn2HqTPKkhKZHgG+9+hTDdZ735jZEd7iP5RSS+XvEBemCYOmUtSWy27GZCke/hitsU7 bCCH7Crw0xfPU8QEaw9DF5khF4SMryXYppgATeNQ7YK56jBcUq8vSHjxJlEmEaZyZ8vy IhCRTBVserg8H4UCGLwpmsl7GeKiOMfL0IyWogWzkbECvuA2mETKRKIKaMFnEQ73SawF yXvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:mime-version:dkim-signature; bh=E3ZzpIcBog2zjAykMMkyaeEdu/UE5HLcjw3UeNdWEM4=; fh=jasI5PmrOKbCgW+nY4NEZKC3l4mk2A2EevaUnStXPs8=; b=k6zHDjOy0k+9GNkODdijSVCBj5vopxU4A2J+l1Cjg8Em2eUZfrIhj/RzqBI4r58EY2 KGeapLRuPjm8NZap29Z4HimcUqdopKjy+3O7pAykOtaWMFTReahjhC5Ij0zR4zWl381Q r3ueROdCTPHjxlgp0quId9mZrMjs95/1bYlAYXTystF1CDZzKh2fk+9TnwWzw++vczUT +Ivp8UG1xgCl3HdA2YMDDQSoBrb1ldejrsCio/dCMp3yUqXkTyjPQAhdABrrRL/Jfgq7 4u3vwOq4cENrJUHt9PiP88pxGbl7V0G97O7DyV9IljggrcapZXeYr1V/PAlh5yqzcNtg q8hQ==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778309938; x=1778914738; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=E3ZzpIcBog2zjAykMMkyaeEdu/UE5HLcjw3UeNdWEM4=; b=SxvwGLS7H0Ckvvu1KPV7bO5L0Lg3aGFSD2QBbZFMWGj4ZWrB0GaoZPFOdvxSI/2WcN Xj2SrJV0dwz6aZDHaXAM9H3PoYrpjl9/AlvStsyu0dPLBGu2GLE3iEB0OjSFxOMso3Y3 4uyAb/+IdrhXQE22WVyAbeT+j67E6Paxx/wBwmWqe3ZF0CtlBb6zLaRhQXfCalR+R89+ znLDuXLJU4KHplUVdEl86QMwmaheRPm24ryGCpBXsFVjKXvYzU2u35UTbKmOyIxVm+ij 8pce5H5IgUZM5VUvsahgz/vxWPSinWKeEX/3A09NQNB1tLf2TrTQKykwm5iLHa/HttEX rSDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778309938; x=1778914738; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=E3ZzpIcBog2zjAykMMkyaeEdu/UE5HLcjw3UeNdWEM4=; b=SieG4OM/lWdJWAtoEYkUmV7gALUxafq6LkQNVUeTWVqqaa2wEGrya5sDdKTxK00s+A YVwwM+FzCrTxCdyUd1dKjVL4pFu8XrKOq2aSxtA5Wg/2PLghMWf8MyfB+3iaq4BPr1zD SgxjSsviX9tFf2Zzy5G2jStReXVTbpbz/Am5Qxmo2bJW80aNmwgJBAhZSQXg+LFbunm1 d1tXwt9pqfGyt47rcBxo9jPj2tAQzBwVQpDPQhv7m180suTLYb6HOW+Bw9c8MmmfbvPP DSNcPOIHEgn9YDHJAhL+tn1fupBOfKY0UlPufyLWxAGrbrrABFnjPS8iRmahm9UnACVI TqQA== X-Forwarded-Encrypted: i=1; AFNElJ+O/euk0fpZckYj5MiCHvcSM3aD3XF2TQ0Ri9g+LsjWKHSuvlhv8HLZQ+gPbQBe2XsQBl1hBtSZemH7WkM=@vger.kernel.org X-Gm-Message-State: AOJu0Yy8cWP6Ua0dFF22djV8KOpOUdPA9is4U16eqOiPA0gRvLpsQWvB Eyb6+j1f02uKiTKfijtnUVSmcWFrtpxfHEQLndi6tMyVKes0Ex735ha1MAjP+/4lNKpaWczooQQ EAC9PCypdq+wycgmf6C/fbJUq/GSS6YpaGDmxki8= X-Gm-Gg: Acq92OF3Qv5y/8z+GUTAvLRxRpPC+LeoV43VQiwBQEDe5bw2kqwANzBJIkp0fUMBzuW yfJYBHlEdyoqF22HCw2IeLp72jV4UWK4we4UFx7dOcpCjrjDBH0Abn5FPOCD0g+ngbbu33iFXhJ dwL7v1uLbJ6LCU7T4m7slL4vDau2Lh1xOUKuHC3uCm0xWwT35sGY0KHD0v1ktr8GUoAWxIRQlei ljjxYog1AyP4GLN1NHz00hugxDwXqiUdWXU29SmGuah0sPIvQrS1rCBWeozhxRbDJObWBt1WbrG Oh0+MXP4vao59dco4jkNLTLa1odovp/lpC8Uz2FA X-Received: by 2002:a05:6402:e94:b0:671:8ba1:e8ab with SMTP id 4fb4d7f45d1cf-67d63d7ef4amr7643931a12.1.1778309937518; Fri, 08 May 2026 23:58:57 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: =?UTF-8?B?5pyo5Y+j55KD6Z+z?= Date: Sat, 9 May 2026 15:58:45 +0900 X-Gm-Features: AVHnY4Jm_ebRILmB2uHfdYlz90IiPkPJ0DPNDTLz42rzdOq3SYR5j5oNNsVE12g Message-ID: Subject: [PATCH] staging: vme_user: validate slave window size against buffer size To: "gregkh@linuxfoundation.org" Cc: linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org, security@kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This patch addresses the OOB read/write reported earlier in the security@kernel.org thread (now handled publicly per Greg's and Willy's guidance). Tested on Linux 7.1.0-rc2 with KASAN; all three reproducers fail with -EINVAL after applying this patch and produce no KASAN splat. From 506ecfc9b8608fb3a56477b8fd205238a1bf66ff Mon Sep 17 00:00:00 2001 From: Rion Kiguchi Date: Sat, 9 May 2026 15:38:33 +0900 Subject: [PATCH] staging: vme_user: validate slave window size against buff= er size The VME_SET_SLAVE ioctl in drivers/staging/vme_user/vme_user.c accepts a user-controlled slave.size and forwards it to vme_slave_set() without comparing it against image[minor].size_buf. The slave-image kernel buffer is allocated at probe time with a fixed size of PCI_BUF_SIZE (0x20000 / 128 KiB), but the configured VME window size can be made much larger via the ioctl. The subsequent read() / write() handlers (vme_user_read / vme_user_write) clamp the I/O range against vme_get_size() (the configured window size, attacker-controlled) but never consult size_buf. The slave I/O paths buffer_to_user() and buffer_from_user() then index image[minor].kern_buf with *ppos values up to image_size - 1, well beyond the actual allocation. Result: a local user with read/write access to /dev/bus/vme/s* can trigger out-of-bounds read and write of the kernel slab adjacent to the slave-image buffer. Fix: reject slave.size > size_buf in the VME_SET_SLAVE handler. Also add defensive bounds checks against size_buf in buffer_to_user() and buffer_from_user() so that the I/O paths cannot exceed the allocation even if a future ioctl path forgets to validate. Reported-by: Pochix1103 Cc: stable@vger.kernel.org Signed-off-by: Rion Kiguchi --- drivers/staging/vme_user/vme_user.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c index 11e25c2f6..41b8d5b51 100644 --- a/drivers/staging/vme_user/vme_user.c +++ b/drivers/staging/vme_user/vme_user.c @@ -156,6 +156,11 @@ static ssize_t buffer_to_user(unsigned int minor, char __user *buf, { void *image_ptr; + if (*ppos < 0 || (u64)*ppos >=3D image[minor].size_buf || + count > image[minor].size_buf - (u64)*ppos) { + pr_warn_ratelimited("%s: out-of-bounds access\n", __func__); + return -EINVAL; + } image_ptr =3D image[minor].kern_buf + *ppos; if (copy_to_user(buf, image_ptr, (unsigned long)count)) return -EFAULT; @@ -168,6 +173,11 @@ static ssize_t buffer_from_user(unsigned int minor, const char __user *buf, { void *image_ptr; + if (*ppos < 0 || (u64)*ppos >=3D image[minor].size_buf || + count > image[minor].size_buf - (u64)*ppos) { + pr_warn_ratelimited("%s: out-of-bounds access\n", __func__); + return -EINVAL; + } image_ptr =3D image[minor].kern_buf + *ppos; if (copy_from_user(image_ptr, buf, (unsigned long)count)) return -EFAULT; @@ -394,6 +404,14 @@ static int vme_user_ioctl(struct inode *inode, struct file *file, return -EFAULT; } + /* + * Reject window sizes larger than the kernel buffer + * allocated at probe time, otherwise subsequent + * read/write would access memory beyond kern_buf. + */ + if (slave.size > image[minor].size_buf) + return -EINVAL; + /* XXX We do not want to push aspace, cycle and width * to userspace as they are */ @@ -401,7 +419,6 @@ static int vme_user_ioctl(struct inode *inode, struct file *file, slave.enable, slave.vme_addr, slave.size, image[minor].pci_buf, slave.aspace, slave.cycle); - break; } break; --=20 2.43.0