| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1e1c082c-0c94-6594-d02c-9f7fbab80b0b@fujitsu.com>
Date: Tue, 11 Apr 2023 01:33:28 +0000
From: "Zhijian Li (Fujitsu)" <lizhijian@...itsu.com>
To: Guoqing Jiang <guoqing.jiang@...ux.dev>,
"haris.iqbal@...os.com" <haris.iqbal@...os.com>,
"jinpu.wang@...os.com" <jinpu.wang@...os.com>,
"jgg@...pe.ca" <jgg@...pe.ca>, "leon@...nel.org" <leon@...nel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH for-next 3/3] RDMA/rtrs: Avoid use-after-free in
rtrs_clt_rdma_cm_handler
On 10/04/2023 21:13, Guoqing Jiang wrote:
>
>
> On 4/10/23 14:43, Li Zhijian wrote:
>> Currently, con will be destroyed when wait_event_interruptible_timeout()
>> returns ERESTARTSYS. But the in-flight event handler
>> rtrs_clt_rdma_cm_handler() could be rescheduled/wakeup which
>> may cause a use-after-free.
>>
>> WARNING: CPU: 0 PID: 14766 at drivers/infiniband/ulp/rtrs/rtrs-clt.c:1687 rtrs_clt_rdma_cm_handler+0x620/0x640 [rtrs_client]
>> Modules linked in: rnbd_client rtrs_client rtrs_core rdma_cm iw_cm ib_cm rdma_rxe ib_uverbs ib_core libiscsi scsi_transport_iscsi crc32_generic udp_tunnel dax_pmem nd_pmem nd_btt virtiofs crc32c_intel nvme fuse nvme_core nfit
>> libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ib_core]
>> CPU: 0 PID: 14766 Comm: kworker/u2:3 Kdump: loaded Tainted: G W 6.2.0-rc6-roce-flush+ #56
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
>> Workqueue: ib_addr process_one_req [ib_core]
>> RIP: 0010:rtrs_clt_rdma_cm_handler+0x620/0x640 [rtrs_client]
>> Code: 00 0f 85 5f fd ff ff 4c 8b 23 41 bd f4 ff ff ff e9 95 fb ff ff 0f 0b 4c 89 f7 41 bd ea ff ff ff e8 75 c8 92 ec e9 4b ff ff ff <0f> 0b 4c 89 f7 41 bd ea ff ff ff e8 60 c8 92 ec e9 36 ff ff ff e8
>> RSP: 0018:ffffa4ef41cdbc60 EFLAGS: 00010246
>> RAX: 0000000000000000 RBX: ffff9372c394e600 RCX: 0000000000000001
>> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffad634277
>> RBP: ffffa4ef41cdbd00 R08: 0000000000000000 R09: 0000000000000001
>> R10: 0000000000003ff3 R11: 0000000000000000 R12: ffff9372c3164800
>> R13: ffff9372c3164800 R14: ffff9372c394e640 R15: ffff9372c5219020
>> FS: 0000000000000000(0000) GS:ffff9372fbc00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f35bb7d5de0 CR3: 0000000020c2a006 CR4: 00000000001706f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>> <TASK>
>> ? mark_held_locks+0x49/0x80
>> ? lock_is_held_type+0xd7/0x130
>> ? cma_cm_event_handler+0x49/0x200 [rdma_cm]
>> cma_cm_event_handler+0x49/0x200 [rdma_cm]
>> addr_handler+0xf1/0x1e0 [rdma_cm]
>> ? lock_acquire+0xca/0x2f0
>> ? lock_acquire+0xda/0x2f0
>> process_one_req+0x43/0x170 [ib_core]
>> process_one_work+0x274/0x590
>> worker_thread+0x4f/0x3d0
>> ? __pfx_worker_thread+0x10/0x10
>> kthread+0xe7/0x110
>> ? __pfx_kthread+0x10/0x10
>> ret_from_fork+0x2c/0x50
>> </TASK>
>> irq event stamp: 1432669
>> hardirqs last enabled at (1432683): [<ffffffffac508eb2>] __up_console_sem+0x52/0x60
>> hardirqs last disabled at (1432698): [<ffffffffac508e97>] __up_console_sem+0x37/0x60
>> softirqs last enabled at (1432518): [<ffffffffac48c985>] __irq_exit_rcu+0xc5/0x120
>> softirqs last disabled at (1432509): [<ffffffffac48c985>] __irq_exit_rcu+0xc5/0x120
>> ---[ end trace 0000000000000000 ]---
>>
>> Signed-off-by: Li Zhijian <lizhijian@...itsu.com>
>> ---
>> drivers/infiniband/ulp/rtrs/rtrs-clt.c | 14 ++++++++++----
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/infiniband/ulp/rtrs/rtrs-clt.c b/drivers/infiniband/ulp/rtrs/rtrs-clt.c
>> index 4c8f42e46e2f..760a7eb51297 100644
>> --- a/drivers/infiniband/ulp/rtrs/rtrs-clt.c
>> +++ b/drivers/infiniband/ulp/rtrs/rtrs-clt.c
>> @@ -2074,6 +2074,7 @@ static int create_cm(struct rtrs_clt_con *con)
>> rtrs_err(s, "Failed to resolve address, err: %d\n", err);
>> goto destroy_cm;
>> }
>> +again:
>> /*
>> * Combine connection status and session events. This is needed
>> * for waiting two possible cases: cm_err has something meaningful
>> @@ -2083,10 +2084,15 @@ static int create_cm(struct rtrs_clt_con *con)
>> clt_path->state_wq,
>> con->cm_err || clt_path->state != RTRS_CLT_CONNECTING,
>> msecs_to_jiffies(RTRS_CONNECT_TIMEOUT_MS));
>> - if (err == 0 || err == -ERESTARTSYS) {
>> - if (err == 0)
>> - err = -ETIMEDOUT;
>> - /* Timedout or interrupted */
>> + if (err == -ERESTARTSYS) {
>> + /* interrupted,
>> + * try again to avoid the in-flight rtrs_clt_rdma_cm_handler()
>> + * getting a use-after-free
>> + */
>> + goto again;
>> + } else if (err == 0) {
>> + err = -ETIMEDOUT;
>> + /* Timedout */
>> goto errr;
>> }
>
> Can event handler still be triggered in case of timeout?
I have never hit such race.
>
> And I guess either stop_cm -> rdma_disconnect or destroy_cm -> rdma_destroy_id
> should prevent this kind of racy issue.
In practice, they are possible that rtrs_clt_rdma_cm_handler() is in-flight during
'either stop_cm -> rdma_disconnect or destroy_cm -> rdma_destroy_id'. rtrs_clt_rdma_cm_handler() and
cm's cleanup path need to hold mutex_lock(&con->con_mutex), once cm's cleanup path get this lock first
rtrs_clt_rdma_cm_handler has to sleep, when rtrs_clt_rdma_cm_handler is wakeup again, some resources has been
freed by cm's cleanup path.
Thanks
>
> Thanks,
> Guoqing
Powered by blists - more mailing lists