Re: [PATCH 1/3] can: rcar_canfd: Fix dangling pointer on channel probe failure

[sashiko-bot@kernel.org]

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

New issues:
- [High] The patch introduces a Use-After-Free by dereferencing `priv` immediately after it has been freed, which can lead to an Out-Of-Bounds NULL write primitive.

Pre-existing issues:
- [High] The lifecycle of the dynamically allocated `priv` is shorter than the `devm`-managed IRQ handlers, leading to a potential use-after-free if an interrupt occurs during teardown.
--

commit e7cd96500f76ea63fe797db226dd1a89ff157846
Author: Biju Das <biju.das.jz@bp.renesas.com>

can: rcar_canfd: Fix dangling pointer on channel probe failure
    
In rcar_canfd_channel_probe(), the channel pointer is saved globally
via gpriv->ch[priv->channel] = priv. If register_candev() fails
shortly after, the error path uses free_candev(ndev) to release the
memory but leaves the pointer in the global array.

> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index eaf8cac780387..5aafbab85da67 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -1982,6 +1982,7 @@ static int rcar_canfd_channel_probe(struct rcar_canfd_global *gpriv, u32 ch,
>  	netif_napi_del(&priv->napi);
>  fail:
>  	free_candev(ndev);

[Severity: High]
This is a pre-existing issue, but does the use of devm_request_irq() earlier
in rcar_canfd_channel_probe() create a lifetime mismatch with this
free_candev() call?

The driver requests channel interrupts using devm_request_irq() with priv
(which is allocated via alloc_candev()) as the dev_id. If a failure occurs
and we hit this fail path, or during teardown in rcar_canfd_channel_remove(),
the memory for priv is synchronously freed by free_candev().

However, because the IRQ was allocated with the devm_ API, free_irq() is not
called until the device's devres cleanup phase, which executes later.

If a spurious hardware interrupt fires during the vulnerable window between
free_candev() and devres cleanup, could the handler
(rcar_canfd_channel_err_interrupt) execute with and dereference the freed
priv pointer?

> +	gpriv->ch[priv->channel] = NULL;

[Severity: High]
Does this cause a use-after-free?

The free_candev(ndev) call immediately above synchronously frees the memory
block containing both ndev and the inline private data priv. Evaluating
gpriv->ch[priv->channel] directly dereferences the newly freed priv pointer.

If memory debugging is enabled (like SLUB poisoning), the freed memory might
be filled with poison bytes, which could lead to an out-of-bounds write here
when it reads a poison value for priv->channel.

>  	return err;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630135119.104774-1-biju.das.jz@bp.renesas.com?part=1