From: Eric Farman <farman@linux.ibm.com>
To: sohu0106 <sohu0106@126.com>,
vneethv@linux.ibm.com, oberpar@linux.ibm.com
Cc: linux-s390@vger.kernel.org
Subject: Re: buffer overflow in vfio_ccw_async_region_write/vfio_ccw_async_region_read
Date: Tue, 30 Aug 2022 15:13:10 -0400 [thread overview]
Message-ID: <9fe918c32c769e47dd38e1b48f5eb35f1bd31976.camel@linux.ibm.com> (raw)
In-Reply-To: <255c7ef5.6bf9.181f1d3637e.Coremail.sohu0106@126.com>
(Apologies for the delay; I was on holiday when this came in and it was
lost in the noise.)
On Tue, 2022-07-12 at 17:52 +0800, sohu0106 wrote:
> >
> > In the vfio_ccw_async_region_write/vfio_ccw_async_region_read >
> > function of drivers/s390/cio/vfio_ccw_async.c, parameter "size_t >
> > count" is pass by userland, if "count" is very large, it will
> > bypass > "if (pos + count > sizeof(*region))".(such as
> > count=0xffffffff). Then > it will lead to buffer overflow in
> > "copy_from_user((void *)region + > pos, buf, count)".
There are some mechanical problems with this patch. It needs a Signed-
off-by tag, and is not applicable in its current form. All easy to
resolve, and documented in:
Documentation/process/submitting-patches.rst
Having said that, I'm not sure that the problem exists as you describe.
In my tests, submitting a very large count (0xffffffff, per your
example) gets capped to MAX_RW_COUNT [1] before it gets here. If you
have a mechanism that shows otherwise, I'd like to see it so that I can
revisit my own test scenarios. Seeing it fail would imply that the
async region is not the only one affected, and a new version of this
patch would need to also address the io and schib regions in vfio-ccw.
Thanks,
Eric
[1]
https://lore.kernel.org/all/CAADWXX9rrESSEGmA4C9F85E9jo7H-pv+CUtyAU_kyB=DfcHRpA@mail.gmail.com/
> >
> >
> >
> >
> > diff --git a/vfio_ccw_async.c_org b/vfio_ccw_async.c
> > index 7a838e3..33339ad 100644
> > --- a/vfio_ccw_async.c_org
> > +++ b/vfio_ccw_async.c
> > @@ -21,7 +21,7 @@ static ssize_t vfio_ccw_async_region_read(struct
> > > vfio_ccw_private *private,
> > struct ccw_cmd_region *region;
> > int ret;
> >
> >
> > - if (pos + count > sizeof(*region))
> > + if (pos + count > sizeof(*region) && pos + count > pos)
> > return -EINVAL;
> >
> >
> > mutex_lock(&private->io_mutex);
> > @@ -43,7 +43,7 @@ static ssize_t vfio_ccw_async_region_write(struct
> > > vfio_ccw_private *private,
> > struct ccw_cmd_region *region;
> > int ret;
> >
> >
> > - if (pos + count > sizeof(*region))
> > + if (pos + count > sizeof(*region) && pos + count > pos)
> > return -EINVAL;
> >
> >
> > if (!mutex_trylock(&private->io_mutex))
> >
prev parent reply other threads:[~2022-08-30 19:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 9:52 buffer overflow in vfio_ccw_async_region_write/vfio_ccw_async_region_read sohu0106
2022-08-30 19:13 ` Eric Farman [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fe918c32c769e47dd38e1b48f5eb35f1bd31976.camel@linux.ibm.com \
--to=farman@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=sohu0106@126.com \
--cc=vneethv@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox