From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Doug Ledford <dledford@redhat.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH rdma-next 6/6] RDMA/srpt: Use private_data_len instead of hardcoded value
Date: Mon, 28 Oct 2019 15:19:17 +0200 [thread overview]
Message-ID: <20191028131917.GE5146@unreal> (raw)
In-Reply-To: <20191028131319.GA15102@ziepe.ca>
On Mon, Oct 28, 2019 at 10:13:19AM -0300, Jason Gunthorpe wrote:
> On Sun, Oct 20, 2019 at 10:15:59AM +0300, Leon Romanovsky wrote:
> > diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
> > index daf811abf40a..e66366de11e9 100644
> > --- a/drivers/infiniband/ulp/srpt/ib_srpt.c
> > +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
> > @@ -2609,7 +2609,7 @@ static int srpt_cm_handler(struct ib_cm_id *cm_id,
> > case IB_CM_REJ_RECEIVED:
> > srpt_cm_rej_recv(ch, event->param.rej_rcvd.reason,
> > event->private_data,
> > - IB_CM_REJ_PRIVATE_DATA_SIZE);
> > + event->private_data_len);
>
> So, I took a look and found a heck of a lot more places assuming the
> size of private data that really should be checked if we are going to
> introduce a buffer length here.
But we are not interested to make it dynamic, "private_data_len" has
constant size according to IBTA spec, I just don't want users to be
aware of this.
Why should we add the below checks if it wasn't before?
>
> This is the first couple I noticed, but there were many many more and
> they all should be handled..
>
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2677,9 +2677,14 @@ static void srp_ib_cm_rej_handler(struct ib_cm_id *cm_id,
> break;
>
> case IB_CM_REJ_CONSUMER_DEFINED:
> + if (event->private_data_len < sizeof(struct srp_login_rej)) {
> + ch->status = -ECONNRESET;
> + break;
> + }
> +
>
> --- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
> @@ -985,12 +985,15 @@ static int ipoib_cm_rep_handler(struct ib_cm_id *cm_id,
> {
> struct ipoib_cm_tx *p = cm_id->context;
> struct ipoib_dev_priv *priv = ipoib_priv(p->dev);
> struct ipoib_cm_data *data = event->private_data;
> struct sk_buff_head skqueue;
> struct ib_qp_attr qp_attr;
> int qp_attr_mask, ret;
> struct sk_buff *skb;
>
> + if (event->private_data_len < sizeof(*data))
> + return -EINVAL;
> +
>
>
> Thanks,
> Jason
next prev parent reply other threads:[~2019-10-28 13:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-20 7:15 [PATCH rdma-next 0/6] CM cleanup Leon Romanovsky
2019-10-20 7:15 ` [PATCH rdma-next 1/6] RDMA/cm: Delete unused cm_is_active_peer function Leon Romanovsky
2019-10-20 7:15 ` [PATCH rdma-next 2/6] RDMA/cm: Use specific keyword to check define Leon Romanovsky
2019-10-20 7:15 ` [PATCH rdma-next 3/6] RDMA/cm: Update copyright together with SPDX tag Leon Romanovsky
2019-10-20 7:15 ` [PATCH rdma-next 4/6] RDMA/cm: Delete useless QPN masking Leon Romanovsky
2019-10-20 8:48 ` Or Gerlitz
2019-10-20 8:54 ` Leon Romanovsky
2019-10-28 12:52 ` Jason Gunthorpe
2019-10-28 13:13 ` Leon Romanovsky
2019-10-28 13:44 ` Jason Gunthorpe
2019-10-28 14:02 ` Leon Romanovsky
2019-10-20 7:15 ` [PATCH rdma-next 5/6] RDMA/cm: Provide private data size to CM users Leon Romanovsky
2019-10-20 7:15 ` [PATCH rdma-next 6/6] RDMA/srpt: Use private_data_len instead of hardcoded value Leon Romanovsky
2019-10-24 17:01 ` Bart Van Assche
2019-10-28 13:13 ` Jason Gunthorpe
2019-10-28 13:19 ` Leon Romanovsky [this message]
2019-10-28 13:43 ` Jason Gunthorpe
2019-10-28 14:06 ` Leon Romanovsky
2019-10-28 13:17 ` [PATCH rdma-next 0/6] CM cleanup Jason Gunthorpe
2019-10-28 13:20 ` Leon Romanovsky
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=20191028131917.GE5146@unreal \
--to=leon@kernel.org \
--cc=bvanassche@acm.org \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.