Re: [PATCH v2 (repost)] can: j1939: j1939_sk_bind(): fix j1939_ecu leak when re-bind failed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Race condition between socket re-bind and netdevice unregister leads to a permanent netdevice refcount leak and indefinite hang.
--

commit b8691a5ee88f84f344aebc052218bc8abf2cba8a
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

can: j1939: j1939_sk_bind(): fix j1939_ecu leak when re-bind failed

This commit defers the removal and release of the old ECU references during
a socket re-bind operation until after successfully acquiring new resources.
This resolves a netdevice refcount leak that occurred when
j1939_local_ecu_get() failed during the bind process.

> diff --git a/net/can/j1939/socket.c b/net/can/j1939/socket.c
> index 50a598ef5fd4a..24efb25c58c3f 100644
> --- a/net/can/j1939/socket.c
> +++ b/net/can/j1939/socket.c
[ ... ]
> @@ -519,22 +517,31 @@ static int j1939_sk_bind(struct socket *sock, struct sockaddr_unsized *uaddr, in
[ ... ]
> +	/* drop old references after re-bind() succeeded */
> +	if (was_bound) {
> +		j1939_jsk_del(priv, jsk);
> +		j1939_local_ecu_put(priv, jsk->addr.src_name, jsk->addr.sa);
> +	}
> +
>  	/* set default transmit pgn */
>  	if (j1939_pgn_is_valid(addr->can_addr.j1939.pgn))
>  		jsk->pgn_rx_filter = addr->can_addr.j1939.pgn;
>  	jsk->addr.src_name = addr->can_addr.j1939.name;
>  	jsk->addr.sa = addr->can_addr.j1939.addr;
>  
> -	/* get new references */
> -	ret = j1939_local_ecu_get(priv, jsk->addr.src_name, jsk->addr.sa);
> -	if (ret) {
> -		j1939_netdev_stop(priv);
> -		jsk->priv = NULL;
> -		synchronize_rcu();
> -		j1939_priv_put(priv);
> -		goto out_release_sock;
> -	}
> -
>  	j1939_jsk_add(priv, jsk);

[Severity: High]
This isn't a bug introduced by this patch, but does this sequence leave a race
window between socket re-bind and netdevice unregister?

When the socket is temporarily unlinked via j1939_jsk_del() and then added
back via j1939_jsk_add() in j1939_sk_bind(), can a concurrent netdevice
unregister operation completely miss the socket?

If an interface is being unregistered (e.g. via ip link del) while a socket
is re-binding to the same interface, j1939_sk_netdev_event_unregister()
could scan the priv->j1939_socks list during this gap:

net/can/j1939/socket.c:j1939_sk_netdev_event_unregister() {
    ...
    read_lock_bh(&priv->j1939_socks_lock);
    list_for_each_entry(jsk, &priv->j1939_socks, list) {
    ...
}

If the unregister notifier iterates the list while the socket is removed,
doesn't the unregister process bypass cleaning up this socket?

Could this result in the socket permanently holding a reference to the
net_device via j1939_priv, causing an indefinite hang in
netdev_wait_allrefs()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/deb3ac27-5eaf-406a-9bf4-733cc43ecaba@I-love.SAKURA.ne.jp?part=1