2017-09-04 13:37:13

by Colin King

[permalink] [raw]
Subject: [PATCH][V2] RDMA/nes: do not leak uninitialized resp.reserved to userspace Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

From: Colin Ian King <[email protected]>

resp.reserved has not been initialized and so the copy_to_user (via
ib_copy_to_udata) is copying uninitialized data from the stack back
to user space which is a potential information leak. Fix this by
initializing all of resp to zero.

V2: Initialize all of the struct rather than just resp.reserved as
suggested by Leon Romanovsky.

Signed-off-by: Colin Ian King <[email protected]>
---
drivers/infiniband/hw/nes/nes_verbs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/nes/nes_verbs.c b/drivers/infiniband/hw/nes/nes_verbs.c
index f0dc5f4aa177..8998d11449c0 100644
--- a/drivers/infiniband/hw/nes/nes_verbs.c
+++ b/drivers/infiniband/hw/nes/nes_verbs.c
@@ -1437,7 +1437,7 @@ static struct ib_cq *nes_create_cq(struct ib_device *ibdev,
struct nes_hw_cqp_wqe *cqp_wqe;
struct nes_pbl *nespbl = NULL;
struct nes_create_cq_req req;
- struct nes_create_cq_resp resp;
+ struct nes_create_cq_resp resp = { 0 };
u32 cq_num = 0;
u32 opcode = 0;
u32 pbl_entries = 1;
--
2.14.1


2017-09-04 13:56:28

by Leon Romanovsky

[permalink] [raw]
Subject: Re: [PATCH][V2] RDMA/nes: do not leak uninitialized resp.reserved to userspace Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

On Mon, Sep 04, 2017 at 02:37:05PM +0100, Colin King wrote:
> From: Colin Ian King <[email protected]>
>
> resp.reserved has not been initialized and so the copy_to_user (via
> ib_copy_to_udata) is copying uninitialized data from the stack back
> to user space which is a potential information leak. Fix this by
> initializing all of resp to zero.
>
> V2: Initialize all of the struct rather than just resp.reserved as
> suggested by Leon Romanovsky.

Small nitpick, it is better to put changelog under "---" marker, so
it won't be visible in the git log.

Thanks
Reviewed-by: Leon Romanovsky <[email protected]>


Attachments:
(No filename) (622.00 B)
signature.asc (833.00 B)
Download all attachments

2017-09-05 14:40:47

by Chien Tin Tung

[permalink] [raw]
Subject: Re: [PATCH][V2] RDMA/nes: do not leak uninitialized resp.reserved to userspace Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

On Mon, Sep 04, 2017 at 02:37:05PM +0100, Colin King wrote:
> From: Colin Ian King <[email protected]>
>
> resp.reserved has not been initialized and so the copy_to_user (via
> ib_copy_to_udata) is copying uninitialized data from the stack back
> to user space which is a potential information leak. Fix this by
> initializing all of resp to zero.

Reserved field is not copied as the length of reserved is subtracted
from the size of resp and passed to ib_copy_to_udata.

if (ib_copy_to_udata(udata, &resp, sizeof resp - sizeof resp.reserved)) {


This patch is not necessary.

Chien

2017-09-05 14:45:15

by Colin King

[permalink] [raw]
Subject: Re: [PATCH][V2] RDMA/nes: do not leak uninitialized resp.reserved to userspace Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit

On 05/09/17 15:40, Chien Tin Tung wrote:
> On Mon, Sep 04, 2017 at 02:37:05PM +0100, Colin King wrote:
>> From: Colin Ian King <[email protected]>
>>
>> resp.reserved has not been initialized and so the copy_to_user (via
>> ib_copy_to_udata) is copying uninitialized data from the stack back
>> to user space which is a potential information leak. Fix this by
>> initializing all of resp to zero.
>
> Reserved field is not copied as the length of reserved is subtracted
> from the size of resp and passed to ib_copy_to_udata.
>
> if (ib_copy_to_udata(udata, &resp, sizeof resp - sizeof resp.reserved)) {
>
>
> This patch is not necessary.

Apologies, I completely overlooked that.

>
> Chien
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>