linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] romfs: Fix uninitialized memory leak in romfs_dev_read()
@ 2020-08-18  1:32 Jann Horn
  2020-08-18  6:09 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 2+ messages in thread
From: Jann Horn @ 2020-08-18  1:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: David Howells, linux-kernel, Greg Kroah-Hartman

romfs has a superblock field that limits the size of the filesystem;
data beyond that limit is never accessed.

romfs_dev_read() fetches a caller-supplied number of bytes from the
backing device. It returns 0 on success or an error code on failure;
therefore, its API can't represent short reads, it's all-or-nothing.

However, when romfs_dev_read() detects that the requested operation
would cross the filesystem size limit, it currently silently truncates
the requested number of bytes. This e.g. means that when the content
of a file with size 0x1000 starts one byte before the filesystem size
limit, ->readpage() will only fill a single byte of the supplied page
while leaving the rest uninitialized, leaking that uninitialized memory
to userspace.

Fix it by returning an error code instead of truncating the read when
the requested read operation would go beyond the end of the filesystem.

Cc: stable@vger.kernel.org
Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly")
Signed-off-by: Jann Horn <jannh@google.com>
---
 fs/romfs/storage.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/romfs/storage.c b/fs/romfs/storage.c
index 6b2b4362089e..b57b3ffcbc32 100644
--- a/fs/romfs/storage.c
+++ b/fs/romfs/storage.c
@@ -217,10 +217,8 @@ int romfs_dev_read(struct super_block *sb, unsigned long pos,
 	size_t limit;
 
 	limit = romfs_maxsize(sb);
-	if (pos >= limit)
+	if (pos >= limit || buflen > limit - pos)
 		return -EIO;
-	if (buflen > limit - pos)
-		buflen = limit - pos;
 
 #ifdef CONFIG_ROMFS_ON_MTD
 	if (sb->s_mtd)

base-commit: bcf876870b95592b52519ed4aafcf9d95999bc9c
-- 
2.28.0.220.ged08abb693-goog


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] romfs: Fix uninitialized memory leak in romfs_dev_read()
  2020-08-18  1:32 [PATCH] romfs: Fix uninitialized memory leak in romfs_dev_read() Jann Horn
@ 2020-08-18  6:09 ` Greg Kroah-Hartman
  0 siblings, 0 replies; 2+ messages in thread
From: Greg Kroah-Hartman @ 2020-08-18  6:09 UTC (permalink / raw)
  To: Jann Horn; +Cc: Andrew Morton, David Howells, linux-kernel

On Tue, Aug 18, 2020 at 03:32:02AM +0200, Jann Horn wrote:
> romfs has a superblock field that limits the size of the filesystem;
> data beyond that limit is never accessed.
> 
> romfs_dev_read() fetches a caller-supplied number of bytes from the
> backing device. It returns 0 on success or an error code on failure;
> therefore, its API can't represent short reads, it's all-or-nothing.
> 
> However, when romfs_dev_read() detects that the requested operation
> would cross the filesystem size limit, it currently silently truncates
> the requested number of bytes. This e.g. means that when the content
> of a file with size 0x1000 starts one byte before the filesystem size
> limit, ->readpage() will only fill a single byte of the supplied page
> while leaving the rest uninitialized, leaking that uninitialized memory
> to userspace.
> 
> Fix it by returning an error code instead of truncating the read when
> the requested read operation would go beyond the end of the filesystem.
> 
> Cc: stable@vger.kernel.org
> Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly")
> Signed-off-by: Jann Horn <jannh@google.com>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-08-18  6:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-18  1:32 [PATCH] romfs: Fix uninitialized memory leak in romfs_dev_read() Jann Horn
2020-08-18  6:09 ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).