From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.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 B909834DCD2 for ; Fri, 7 Aug 2026 06:31:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786084287; cv=none; b=ZHYnr+P4Rumcsd0r1xclAFEAqZY0d4DPIl+VHSor+YpGH7uxP/qL1EqPttyx/sOZOlSNcox7ujyttRQgDFtm98R8EA4i+9wbR5uUZWoqlL5daEgFP4OWHoiojWNG+Mdq26NGbMoewAR2NV582ccibxObQFDwJ7k3UgNqMkm9tiA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786084287; c=relaxed/simple; bh=3lx5y7D2BH46IdHqSY10Ho6u3jWIrliReytwLOs3oXc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hZXVW3uT7GhhkX5peNV42Rollgtbfch6N7D5/3/1epbSKAattzCgWypDMlqbQp/6xyBNrosS3J7mDo14VbC2E1ZQx2qXuoh9cuxu9+OCzRnRdEU+ao6l3zMIJiSAhTOMesXkzKw0wxn/aRqdBSERTkeRr0Y7u2dP6uKDhh512Ak= 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=K/2h5tzq; arc=none smtp.client-ip=209.85.128.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="K/2h5tzq" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4954afac04bso33510745e9.0 for ; Thu, 06 Aug 2026 23:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786084284; x=1786689084; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=7TRI/BMp4S2EUObR2RuO3BEX7TL3pPneQPDQ8x7rfvY=; b=K/2h5tzq83mEXnmcxpO5S7OcapUL8z9Su8t5SMR37AIYWE0bVgsW0ijHwbmxNlANJV TV7cP+f68uOJQFUCv+UhOk4JpIby1hAHJawia25UryYs0Y7c6mArwvOsaxRXMv3xZFhR bze8adSdCjLwHh4FIiMAcs7nOXUqbeL7ylTnwOSydzrQNsW0pvfMmfMy7FxicBxHuvjt tQNWOLFJAhTjm4lCGTNDjDKhrbjHt8d9AxsV3UoLh6pK0LLlf4vaKCJ2pvH+Juuv/voV 8Oh7qiWej9pju1P6mV/lcbukCAaoyEM+2nhqjKUm4n/j1s1Wxf+DiABPBiSqF+7Ic5uT CHBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786084284; x=1786689084; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7TRI/BMp4S2EUObR2RuO3BEX7TL3pPneQPDQ8x7rfvY=; b=hyHPN0lo6sUmeCGnNuu4Za1XuQOQHDb2duDqAWeQBANkmIDoOhRebOK3fpctyIO1Gn jBfM/mXMv1V7TDmcoIqeirrqm43PNdgb3Z+xE3qpfoWD25u4NH6ch29CB8P8y5jzp6vA mwX/OwNIsL03yudrHr2C/1ZpPz4HKcvZogBBugGfN12QiWH8XcXgWF7MucbD/8rt306F GGDpRgkjKFoV9KJAaBd/0V787a/K2QcQdrkEpObu3eVN1xco3wBlBHFIlFh4YcycZhS/ gkkyLuqCMeetn7p5OD3s36D3vtz/jby6KPDavT2QcAD8/8DxyD/qdExdaHIsgiN50+/c DNhQ== X-Forwarded-Encrypted: i=1; AHgh+Rr3B7+UH04AABMAmvZ2WxZh6LZ2HAX5rhwPmGLHk8oZEVnoXU7xuiob9RCAplfZypE8zr9GAuIY9jrdFrE=@vger.kernel.org X-Gm-Message-State: AOJu0YyC618lHLNCtHGjzMwNXL+wVh2YnaiDFAr26KyrPl9p8cbDfqCV 8IAnQwrydM3tA3Wh3azZcZ0tGyGLpozOr4adihKHg8791y4mKxggkHTl X-Gm-Gg: AR+sD12u3jlTSHhcbNkaAeh+LYtftEEGXbxJ6Fytk386egxDDlHl7a1L+AvCb2uD6OP EGtWYoqsLf5Tn59k4l2uelU7fHJMmzlKkGE82k29vxmG0DNxkreRYpFwVulQ1MYyKKxOigomfxL 1mBSn9+hgS1OJesSNEG741gUKnuGh/NTELPF9ye0Bhpc9dfcJ5cZu2UeNnhxvsAi/85XKU95bZM 0TXFNlCAziVci2hcfk+Vu4k4mxbRjDle3QsPdSZuOvyHPtXGEmxfGsWi3B9nlwKX0aXHxbWl8Z7 1uzaTzTUvyKzeo8QBedH7GNxquTmR9NyYEpY03okFNC9Qhd1j6JKsA3gsitCjGUrKwW4VxPKWk9 hKNcmKwG1ezwdzDjVSH82fH5VUOyrPEzeUPhFmAiGsigmx6q6ezp4M7YQL3GYz0Yms3cuAFw4zJ bjph/bzycRjmFjU6Xhw/RPylC4bkw+aLfykIXllnv43+kNlKjOtqJFd3xn X-Received: by 2002:a7b:c854:0:b0:495:5b4a:53b7 with SMTP id 5b1f17b1804b1-4994e7d7320mr218609625e9.19.1786084283885; Thu, 06 Aug 2026 23:31:23 -0700 (PDT) Received: from localhost ([2c0f:3d00:6be:8900:ce5e:9212:ea4b:f30]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995e9f0230sm9334415e9.6.2026.08.06.23.31.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 23:31:23 -0700 (PDT) Date: Fri, 7 Aug 2026 09:31:18 +0300 From: Dan Carpenter To: Som Tripathi Cc: gregkh@linuxfoundation.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging: vme_user: fix bounds check when vme_get_size() returns zero Message-ID: References: <20260807012506.579588-1-tripathisom142004@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260807012506.579588-1-tripathisom142004@gmail.com> On Thu, Aug 06, 2026 at 08:25:06PM -0500, Som Tripathi wrote: > 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; There are probably more than three. :P > 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); It would be better to just add a check here. if (!image_size) return 0; Same for the other. regards, dan carpenter > > /* 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; > }