($INBOX_DIR/description missing)
 help / color / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	syzkaller-bugs@googlegroups.com, linux-unionfs@vger.kernel.org
Subject: [PATCH] ovl: fix out of bounds access warning in ovl_check_fb_len()
Date: Sat, 23 May 2020 16:21:55 +0300
Message-ID: <20200523132155.14698-1-amir73il@gmail.com> (raw)

syzbot reported out of bounds memory access from open_by_handle_at()
with a crafted file handle that looks like this:

  { .handle_bytes = 2, .handle_type = OVL_FILEID_V1 }

handle_bytes gets rounded down to 0 and we end up calling:
  ovl_check_fh_len(fh, 0) => ovl_check_fb_len(fh + 3, -3)

But fh buffer is only 2 bytes long, so accessing struct ovl_fb at
fh + 3 is illegal.

Fixes: cbe7fba8edfc ("ovl: make sure that real fid is 32bit aligned in memory")
Reported-and-tested-by: syzbot+61958888b1c60361a791@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org> # v5.5
Signed-off-by: Amir Goldstein <amir73il@gmail.com>


Another fallout from aligned file handle.
This one seems like a warning that cannot lead to actual harm.
As far as I can tell, with:

  { .handle_bytes = 2, .handle_type = OVL_FILEID_V1 }

kmalloc in handle_to_path() allocates 10 bytes, which means 16 bytes
slab object, so all fields accessed by ovl_check_fh_len() should be
within the slab object boundaries. And in any case, their value
won't change the outcome of EINVAL.

I have added this use case to the xfstest for checking the first bug,
but it doesn't trigger any warning on my kernel (without KASAN) and
returns EINVAL as expected.


 fs/overlayfs/overlayfs.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h
index 76747f5b0517..ffbb57b2d7f6 100644
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -355,6 +355,9 @@ int ovl_check_fb_len(struct ovl_fb *fb, int fb_len);
 static inline int ovl_check_fh_len(struct ovl_fh *fh, int fh_len)
+	if (fh_len < sizeof(struct ovl_fh))
+		return -EINVAL;
 	return ovl_check_fb_len(&fh->fb, fh_len - OVL_FH_WIRE_OFFSET);

                 reply index

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200523132155.14698-1-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=syzkaller-bugs@googlegroups.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

($INBOX_DIR/description missing)

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-unionfs/0 linux-unionfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-unionfs linux-unionfs/ https://lore.kernel.org/linux-unionfs \
	public-inbox-index linux-unionfs

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git