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

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

[Colin King]

From: Colin Ian King <colin.king@canonical.com>

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 <colin.king@canonical.com>
---
 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

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

[Leon Romanovsky]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Mon, Sep 04, 2017 at 02:37:05PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> 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 <leonro@mellanox.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Chien Tin Tung]

On Mon, Sep 04, 2017 at 02:37:05PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
> 
> 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

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

[Colin Ian King]

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 <colin.king@canonical.com>
>>
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>