On 8/19/24 4:24 AM, Ma Ke wrote:
> cxgbi_check_route() dont release the reference acquired by ip_dev_find()
> which introducing a reference count leak. We could remedy this by
> insuring the reference is released.ip_dev_find().
>
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: 9ba682f01e2f ("[SCSI] libcxgbi: common library for cxgb3i and cxgb4i")
> Signed-off-by: Ma Ke <make24@xxxxxxxxxxx>
> ---
> drivers/scsi/cxgbi/libcxgbi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
> index bf75940f2be1..6b0f1e8dac40 100644
> --- a/drivers/scsi/cxgbi/libcxgbi.c
> +++ b/drivers/scsi/cxgbi/libcxgbi.c
> @@ -670,6 +670,7 @@ cxgbi_check_route(struct sockaddr *dst_addr, int ifindex)
> "route to %pI4 :%u, ndev p#%d,%s, cdev 0x%p.\n",
> &daddr->sin_addr.s_addr, ntohs(daddr->sin_port),
> port, ndev->name, cdev);
> + dev_put(ndev);
After we call ip_dev_find can we hit one of the error path gotos like
the test for IFF_UP? If so you would leak the reference in those paths.
The ndev above looks like it could come from the ip_dev_find call when
IFF_LOOPBACK is set or it could come from dst_neigh_lookup call. For the
dst_neigh_lookup case we don't want to do a dev_put do we? If you do,
then we are leaking the reference in the goto error paths.
>
> csk = cxgbi_sock_create(cdev);
> if (!csk) {
