2020-06-15 09:13:15

by Jing Xiangfeng

[permalink] [raw]
Subject: [PATCH] IB/srpt: Fix a potential null pointer dereference

In srpt_cm_req_recv(), it is possible that sdev is NULL,
so we should test sdev before using it.

Signed-off-by: Jing Xiangfeng <[email protected]>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 98552749d71c..72053254bf84 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -2143,7 +2143,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
const struct srp_login_req *req,
const char *src_addr)
{
- struct srpt_port *sport = &sdev->port[port_num - 1];
+ struct srpt_port *sport;
struct srpt_nexus *nexus;
struct srp_login_rsp *rsp = NULL;
struct srp_login_rej *rej = NULL;
@@ -2162,6 +2162,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
if (WARN_ON(!sdev || !req))
return -EINVAL;

+ sport = &sdev->port[port_num - 1];
it_iu_len = be32_to_cpu(req->req_it_iu_len);

pr_info("Received SRP_LOGIN_REQ with i_port_id %pI6, t_port_id %pI6 and it_iu_len %d on port %d (guid=%pI6); pkey %#04x\n",
--
2.17.1


2020-06-15 13:40:13

by Bart Van Assche

[permalink] [raw]
Subject: Re: [PATCH] IB/srpt: Fix a potential null pointer dereference

On 2020-06-15 02:12, Jing Xiangfeng wrote:
> In srpt_cm_req_recv(), it is possible that sdev is NULL,
> so we should test sdev before using it.
>
> Signed-off-by: Jing Xiangfeng <[email protected]>
> ---
> drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
> index 98552749d71c..72053254bf84 100644
> --- a/drivers/infiniband/ulp/srpt/ib_srpt.c
> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
> @@ -2143,7 +2143,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
> const struct srp_login_req *req,
> const char *src_addr)
> {
> - struct srpt_port *sport = &sdev->port[port_num - 1];
> + struct srpt_port *sport;
> struct srpt_nexus *nexus;
> struct srp_login_rsp *rsp = NULL;
> struct srp_login_rej *rej = NULL;
> @@ -2162,6 +2162,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
> if (WARN_ON(!sdev || !req))
> return -EINVAL;
>
> + sport = &sdev->port[port_num - 1];
> it_iu_len = be32_to_cpu(req->req_it_iu_len);
>

Please remove the (!sdev || !req) check instead of making the above
change. It's easy to show that both pointers are always valid.

Thanks,

Bart.

2020-06-16 00:55:53

by Jing Xiangfeng

[permalink] [raw]
Subject: Re: [PATCH] IB/srpt: Fix a potential null pointer dereference



On 2020/6/15 21:37, Bart Van Assche wrote:
> On 2020-06-15 02:12, Jing Xiangfeng wrote:
>> In srpt_cm_req_recv(), it is possible that sdev is NULL,
>> so we should test sdev before using it.
>>
>> Signed-off-by: Jing Xiangfeng <[email protected]>
>> ---
>> drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
>> index 98552749d71c..72053254bf84 100644
>> --- a/drivers/infiniband/ulp/srpt/ib_srpt.c
>> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
>> @@ -2143,7 +2143,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
>> const struct srp_login_req *req,
>> const char *src_addr)
>> {
>> - struct srpt_port *sport = &sdev->port[port_num - 1];
>> + struct srpt_port *sport;
>> struct srpt_nexus *nexus;
>> struct srp_login_rsp *rsp = NULL;
>> struct srp_login_rej *rej = NULL;
>> @@ -2162,6 +2162,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
>> if (WARN_ON(!sdev || !req))
>> return -EINVAL;
>>
>> + sport = &sdev->port[port_num - 1];
>> it_iu_len = be32_to_cpu(req->req_it_iu_len);
>>
>
> Please remove the (!sdev || !req) check instead of making the above
> change. It's easy to show that both pointers are always valid.

OK, I will send a v2 with this change.

Thanks
>
> Thanks,
>
> Bart.
> .
>