From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (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 88FA14B0494 for ; Fri, 7 Aug 2026 01:25:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786065915; cv=none; b=trM9f4cm11rgfcjtpnN/IRpxRTa5d5nV4ilqrAQRGy2SbKVtrX+qfi07O406rru3JpRvCzjqVfyO8EkArcK+NPJaXOAxWv62mNkX2cRLhwRdLAavfn3XhfsLohu/L9uQc/x7NmuRGSxarp3KLUvOgwhXKBF0c17O0vqv/FPTQys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786065915; c=relaxed/simple; bh=M/pt70KtCs+icKAkrRpWwBPECuU1ngaL++gWm6DOHI4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=iALfzCtXitigzFxVub49cz9LVHcklYFLley+04cRnIGLQnS77VQn6Dp4Z71lDb2cVIRzPhdo+ZSXoYUsEIMW72Th/zdrYR3NcuRnd6EvFirbQSqcUD0TTwOHzzGMCkl0hDpYJ/MjzlKbKnwnuIx8IcNii/0Lsd+tcpurRVq0Gmk= ARC-Authentication-Results:i=1; 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=HicFgXE4; arc=none smtp.client-ip=209.85.210.49 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="HicFgXE4" Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-7f18c0e03e3so1514446a34.2 for ; Thu, 06 Aug 2026 18:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786065912; x=1786670712; 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=Qa69CO0lFAMCF1EBY4SDQqVVF+TJtQeI64kkaeeZHXs=; b=HicFgXE4xsf2FU9myiGY4JjxmWf+KdwijJQenGUhbAWqCpFJagoUslHxZEGxe2LW7y +RAj6DkJ2Je1mZoOwbVqXbEX6Qh4yLXNJ0KOY7uSjq3nX7TsFwjlTTrXeqF4XZ5TdNsw H/zzcnDYM7SdU20Q/aUoXdNXOWdRIStMMDHgSPXpQK23ADnuqYBfIYFS2LuDW5PBaJwg ixvjpbMRJYatrvX8+/IA9QwG7GC3xMuuJZW67QlKNkZR3nXtKfkpeNfTl/qX20spxp0A lshUtOMTTwwNoItPM+BqIx2V6GNgtVeTD1JTNLKyy2AFrImm5JZhhRF5unumD6xvJ1uq p1cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786065912; x=1786670712; 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=Qa69CO0lFAMCF1EBY4SDQqVVF+TJtQeI64kkaeeZHXs=; b=WXszqzVYyp181X6lPndZU0mL6L+me5yx0ZvIe/lVxEuHp0PjibEJqYEfMTi7w/ApdF d6D9tbUeWqvHWBLGfSBdNWLfQ/TrIRMoIWMP6CffhHqzyZjMNvvx9NGiiIW9upmm92fb 50bnBBD1Cezfi/MUp9CiL+eKr5+En1/ZGvNT+QC6bHyAmG+7+mrilWh5kyVhso4CzAIG mQ7qoB2gyMLHypAx4zmSnZ4CqmX78nf6ZeL1i93aIzr0DNQko4RbBl7UT5tAQ680Z5Lj 1tswR2WVg/aT1f23IypKu/0vF79EVlF/TPPBO95c/EwJtTQjxxqDKbGev2EvdScRudlp /5NA== X-Forwarded-Encrypted: i=1; AHgh+Rpe0rAQ2uTGT3PVK2VqKXDuG8n6dGXNrA0Ukd3MKcHYZgvpwgheimskBiv2uJQP934AdqHQBP8Zgtu+Npc=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7VOlVT7HL0t9Ipox8L0+i0jqOMaPs61p3EIojzneqPTo/awhS AAh2hD+60Sl9yWOAicgJh5TPeT7kTM0KtUB5GamG/uCRLXfN5rxuK7s= X-Gm-Gg: AR+sD10cefa+g6uxy46xYf50oTV22lrNt9rymfs37MDYu0UhIxxENF44Xzey4IQYILm xeiyirlW5Y9btMtYpa/edOnsLf0wnDUdDjfFr0/eBbUu+B73wTGltWBbaWOpqT5hJ8hhuIEN9ow BDKzDtTfc/3bOypXj5pV/8UI+kamZQ//bFRjZ78UlOXgFqDF9TDBH0Jkeem3d1zhzt2BGHHhe9D UibHfYSALnFT/d8qj/nC5yOmbsqRuXfz3yZ6iv3vLUautqQfRtE9c2RoAGv7KKCV4ge9nifg3fc mQqVjMd44kgPyRBphcJ+ceFjyFQldANis2ReGuqPekRf6NFWcyk/xp2yfzfQfbc0xZsyVC9sYw5 E6Z4EdxxLNqw1n7evZVKsePl8Fd8N0qQIhReszsjMPsXD4F+fQ2JbhKfhqyIg8kJrV7lBzBtSaj zqEd/oj4EASLQFgTu8tARXYIMo9IMvLmKgqfpw8VCBuHBHBvkXm+558rZ7t80lKNCSrJZ2rhfh1 G2yRYKuHI8Chzm9MAqooFzRvympR/dgk5UTWZ4hNZEO1X0ZH4qbebiW X-Received: by 2002:a05:6830:838e:b0:7eb:9464:ac2e with SMTP id 46e09a7af769-7f1e5e321camr11474920a34.11.1786065912320; Thu, 06 Aug 2026 18:25:12 -0700 (PDT) Received: from lone (69-5-138-1.icsincorporated.com. [69.5.138.1]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7f35b7700desm229386a34.18.2026.08.06.18.25.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 18:25:11 -0700 (PDT) From: Som Tripathi To: gregkh@linuxfoundation.org Cc: error27@gmail.com, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, Som Tripathi Subject: [PATCH] staging: vme_user: fix bounds check when vme_get_size() returns zero Date: Thu, 6 Aug 2026 20:25:06 -0500 Message-ID: <20260807012506.579588-1-tripathisom142004@gmail.com> X-Mailer: git-send-email 2.55.0.windows.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit vme_get_size() returns zero on failure, as its kerneldoc in vme.c states. vme_user_read() and vme_user_write() assign it to a size_t and check the file position with: if ((*ppos < 0) || (*ppos > (image_size - 1))) When image_size is zero, image_size - 1 wraps to SIZE_MAX. The test is then never true, so the check does nothing. The following statement, count = image_size - *ppos; wraps the same way whenever *ppos is greater than zero. This is not an out-of-bounds access. resource_to_user() and resource_from_user() clamp count to size_buf, buffer_to_user() and buffer_from_user() clamp it to size_buf - *ppos, and vme_master_read() and vme_master_write() reject an offset greater than the window length. What happens instead is that read() and write() operate on a window whose size the driver failed to read, rather than returning at the check. Compare *ppos against image_size directly. The two forms agree for a non-zero size, the new one is also correct for zero, and both wraps go away. Found by reading the code after Dan Carpenter listed this as one of three outstanding bugs in this driver; see the Link below. Compile tested only. I have no VME hardware. Fixes: f00a86d98a1e ("Staging: vme: add VME userspace driver") Link: https://lore.kernel.org/all/aj0WWwiOzjLGbY5z@stanley.mountain/ Signed-off-by: Som Tripathi Assisted-by: Claude:claude-opus-5 --- drivers/staging/vme_user/vme_user.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/vme_user/vme_user.c b/drivers/staging/vme_user/vme_user.c index a472a38ef..0df30a3c3 100644 --- a/drivers/staging/vme_user/vme_user.c +++ b/drivers/staging/vme_user/vme_user.c @@ -213,7 +213,7 @@ static ssize_t vme_user_read(struct file *file, char __user *buf, size_t count, image_size = vme_get_size(image[minor].resource); /* Ensure we are starting at a valid location */ - if ((*ppos < 0) || (*ppos > (image_size - 1))) { + if ((*ppos < 0) || (*ppos >= image_size)) { mutex_unlock(&image[minor].mutex); return 0; } @@ -255,7 +255,7 @@ static ssize_t vme_user_write(struct file *file, const char __user *buf, image_size = vme_get_size(image[minor].resource); /* Ensure we are starting at a valid location */ - if ((*ppos < 0) || (*ppos > (image_size - 1))) { + if ((*ppos < 0) || (*ppos >= image_size)) { mutex_unlock(&image[minor].mutex); return 0; } -- 2.55.0.windows.1