Re: [PATCH] scsi: cxgbi: fix retry_timer use-after-free on adapter detach

[email protected]
Newsgroups org.kernel.vger.linux-scsi
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Sockets in CTP_ACTIVE_OPEN state permanently leak ATID resources and memory on adapter detach.
- [High] Non-synchronous timer_delete() followed by socket destruction leads to a Use-After-Free.
- [High] Missing state check in the retry timer callbacks sends duplicate open requests, destroying established connections.
--

--- Patch [1]: [PATCH] scsi: cxgbi: fix retry_timer use-after-free on adapter detach ---
commit a8e38255da09728f75742d7fed123ba4827cbc81
Author: Fan Wu <[email protected]>

scsi: cxgbi: fix retry_timer use-after-free on adapter detach

This commit fixes a use-after-free on adapter detach by setting the
CTPF_OFFLOAD_DOWN flag under the socket lock and using timer_delete_sync()
to drain pending callbacks. It also updates the timer callbacks and reply
handlers to check this flag before proceeding.

> diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
> --- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
> +++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
> @@ -556,6 +556,11 @@ static void act_open_retry_timer(struct timer_list *t)
>  
>  	cxgbi_sock_get(csk);
>  	spin_lock_bh(&csk->lock);
> +	if (cxgbi_sock_flag(csk, CTPF_OFFLOAD_DOWN)) {
> +		spin_unlock_bh(&csk->lock);
> +		cxgbi_sock_put(csk);
> +		return;
> +	}

[Severity: High]
This is a pre-existing issue, but does this callback send duplicate open
requests that can destroy established connections?

The callback unconditionally sends an open request without verifying if
csk->state is still CTP_ACTIVE_OPEN. If the timer callback executes
immediately after do_act_establish() transitions the socket to
CTP_ESTABLISHED and drops the lock, the callback will acquire the lock
and blindly send a duplicate CPL_ACT_OPEN_REQ.

The hardware will reject this with CPL_ERR_CONN_EXIST, which causes
do_act_open_rpl() to forcibly tear down the valid connection.

[Severity: High]
This is also a pre-existing issue, but can the non-synchronous timer
cancellation in do_act_establish() lead to a use-after-free?

In do_act_establish(), the timer is canceled non-synchronously:

do_act_establish() {
        ...
        if (csk->retry_timer.function) {
                timer_delete(&csk->retry_timer);
                csk->retry_timer.function = NULL;
        }
        ...
}

If the timer callback is queued on another CPU, it can execute after
the socket drops its lock. If the new connection is rapidly aborted
(e.g., by receiving CPL_ABORT_REQ_RSS), the socket teardown path releases
all references and frees the socket memory.

When the delayed timer callback eventually runs, it will call
cxgbi_sock_get(csk) on freed memory.

[ ... ]

> diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
> --- a/drivers/scsi/cxgbi/libcxgbi.c
> +++ b/drivers/scsi/cxgbi/libcxgbi.c
> @@ -109,6 +109,7 @@ void cxgbi_device_portmap_cleanup(struct cxgbi_device *cdev)
>  			cxgbi_sock_set_flag(csk, CTPF_OFFLOAD_DOWN);
>  			cxgbi_sock_closed(csk);
>  			spin_unlock_bh(&csk->lock);
> +			timer_delete_sync(&csk->retry_timer);
>  			cxgbi_sock_put(csk);

[Severity: High]
This is a pre-existing issue, but does this leak ATID resources and socket
memory for sockets in the CTP_ACTIVE_OPEN state?

Looking at cxgbi_sock_closed(), it returns early for ACTIVE_OPEN sockets:

cxgbi_sock_closed() {
        ...
        if (csk->state == CTP_ACTIVE_OPEN || csk->state == CTP_CLOSED)
                return;
}

This early return bypasses csk_release_offload_resources(). If an adapter
is detached while an active-open connection is pending, the timer callbacks
now immediately return upon seeing CTPF_OFFLOAD_DOWN without advancing
the state or failing the connection.

Without further hardware replies to fail the connection, the socket remains
indefinitely trapped in CTP_ACTIVE_OPEN, leaking the ATID and socket memory.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.