* [PATCH] ovl: potential crash in ovl_fid_to_fh() [not found] <CAOQ4uxj0F9V=FOUANKSATR2E==BoLr6OJMqsJe5QCbOLNR0k0A@mail.gmail.com> @ 2020-05-05 18:07 ` Dan Carpenter 2020-05-05 18:15 ` Amir Goldstein 0 siblings, 1 reply; 3+ messages in thread From: Dan Carpenter @ 2020-05-05 18:07 UTC (permalink / raw) To: Miklos Szeredi, Amir Goldstein; +Cc: linux-unionfs, kernel-janitors The "buflen" value comes from the user and there is a potential that it could be zero. In do_handle_to_path() we know that "handle->handle_bytes" is non-zero and we do: handle_dwords = handle->handle_bytes >> 2; So values 1-3 become zero. Then in ovl_fh_to_dentry() we do: int len = fh_len << 2; So now len is in the "0,4-128" range and a multiple of 4. But if "buflen" is zero it will try to copy negative bytes when we do the memcpy in ovl_fid_to_fh(). memcpy(&fh->fb, fid, buflen - OVL_FH_WIRE_OFFSET); And that will lead to a crash. Thanks to Amir Goldstein for his help with this patch. Fixes: cbe7fba8edfc: ("ovl: make sure that real fid is 32bit aligned in memory") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> --- fs/overlayfs/export.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c index 475c61f53f0fe..0e58213ace6d7 100644 --- a/fs/overlayfs/export.c +++ b/fs/overlayfs/export.c @@ -776,6 +776,9 @@ static struct ovl_fh *ovl_fid_to_fh(struct fid *fid, int buflen, int fh_type) { struct ovl_fh *fh; + if (buflen <= OVL_FH_WIRE_OFFSET) + return ERR_PTR(-EINVAL); + /* If on-wire inner fid is aligned - nothing to do */ if (fh_type = OVL_FILEID_V1) return (struct ovl_fh *)fid; -- 2.26.2 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] ovl: potential crash in ovl_fid_to_fh() 2020-05-05 18:07 ` [PATCH] ovl: potential crash in ovl_fid_to_fh() Dan Carpenter @ 2020-05-05 18:15 ` Amir Goldstein 2020-05-05 18:33 ` [PATCH v2] " Dan Carpenter 0 siblings, 1 reply; 3+ messages in thread From: Amir Goldstein @ 2020-05-05 18:15 UTC (permalink / raw) To: Dan Carpenter; +Cc: Miklos Szeredi, overlayfs, kernel-janitors On Tue, May 5, 2020 at 9:07 PM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > The "buflen" value comes from the user and there is a potential that it > could be zero. In do_handle_to_path() we know that "handle->handle_bytes" > is non-zero and we do: > > handle_dwords = handle->handle_bytes >> 2; > > So values 1-3 become zero. Then in ovl_fh_to_dentry() we do: > > int len = fh_len << 2; > > So now len is in the "0,4-128" range and a multiple of 4. But if > "buflen" is zero it will try to copy negative bytes when we do the > memcpy in ovl_fid_to_fh(). > > memcpy(&fh->fb, fid, buflen - OVL_FH_WIRE_OFFSET); > > And that will lead to a crash. Thanks to Amir Goldstein for his help > with this patch. > > Fixes: cbe7fba8edfc: ("ovl: make sure that real fid is 32bit aligned in memory") > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> > --- > fs/overlayfs/export.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c > index 475c61f53f0fe..0e58213ace6d7 100644 > --- a/fs/overlayfs/export.c > +++ b/fs/overlayfs/export.c > @@ -776,6 +776,9 @@ static struct ovl_fh *ovl_fid_to_fh(struct fid *fid, int buflen, int fh_type) > { > struct ovl_fh *fh; > > + if (buflen <= OVL_FH_WIRE_OFFSET) > + return ERR_PTR(-EINVAL); > + Sorry, I should have been more specific. This check belongs after fh_type != OVL_FILEID_V0 because it is only relevant for OVL_FILEID_V0. For OVL_FILEID_V1 len properly checked by ovl_check_fh_len(). Otherwise feel free to add: Reviewed-by: Amir Goldstein <amir73il@gmail.com> Thanks, Amir. ^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH v2] ovl: potential crash in ovl_fid_to_fh() 2020-05-05 18:15 ` Amir Goldstein @ 2020-05-05 18:33 ` Dan Carpenter 0 siblings, 0 replies; 3+ messages in thread From: Dan Carpenter @ 2020-05-05 18:33 UTC (permalink / raw) To: Miklos Szeredi, Amir Goldstein; +Cc: linux-unionfs, kernel-janitors The "buflen" value comes from the user and there is a potential that it could be zero. In do_handle_to_path() we know that "handle->handle_bytes" is non-zero and we do: handle_dwords = handle->handle_bytes >> 2; So values 1-3 become zero. Then in ovl_fh_to_dentry() we do: int len = fh_len << 2; So now len is in the "0,4-128" range and a multiple of 4. But if "buflen" is zero it will try to copy negative bytes when we do the memcpy in ovl_fid_to_fh(). memcpy(&fh->fb, fid, buflen - OVL_FH_WIRE_OFFSET); And that will lead to a crash. Thanks to Amir Goldstein for his help with this patch. Fixes: cbe7fba8edfc: ("ovl: make sure that real fid is 32bit aligned in memory") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> --- v2: Move the check after the other checks fs/overlayfs/export.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c index 475c61f53f0fe..ed5c1078919cc 100644 --- a/fs/overlayfs/export.c +++ b/fs/overlayfs/export.c @@ -783,6 +783,9 @@ static struct ovl_fh *ovl_fid_to_fh(struct fid *fid, int buflen, int fh_type) if (fh_type != OVL_FILEID_V0) return ERR_PTR(-EINVAL); + if (buflen <= OVL_FH_WIRE_OFFSET) + return ERR_PTR(-EINVAL); + fh = kzalloc(buflen, GFP_KERNEL); if (!fh) return ERR_PTR(-ENOMEM); -- 2.26.2 ^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-05-05 18:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAOQ4uxj0F9V=FOUANKSATR2E==BoLr6OJMqsJe5QCbOLNR0k0A@mail.gmail.com>
2020-05-05 18:07 ` [PATCH] ovl: potential crash in ovl_fid_to_fh() Dan Carpenter
2020-05-05 18:15 ` Amir Goldstein
2020-05-05 18:33 ` [PATCH v2] " Dan Carpenter
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).