Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20211026180740.1953265-1-mailhol.vincent@wanadoo.fr> <20211027073905.aff3mmonp7a3itrn@pengutronix.de>
In-Reply-To: <20211027073905.aff3mmonp7a3itrn@pengutronix.de>
From:   Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Date:   Wed, 27 Oct 2021 17:48:21 +0900
Message-ID: <CAMZ6RqKC2SXsDE2pvNw0LT9TsOHR9W-evTqzv35W+-Dtd-Peow@mail.gmail.com>
Subject: Re: [PATCH v1] can: etas_es58x: es58x_rx_err_msg: fix memory leak in
 error path
To:     Marc Kleine-Budde <mkl@pengutronix.de>
Cc:     linux-can <linux-can@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed. 27 Oct 2021 at 16:39, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 27.10.2021 03:07:40, Vincent Mailhol wrote:
> > In es58x_rx_err_msg(), if can->do_set_mode() fails, the function
> > directly returns without calling netif_rx(skb). This means that the
> > skb previously allocated by alloc_can_err_skb() is not freed. In other
> > terms, this is a memory leak.
> >
> > This patch simply removes the return statement in the error branch and
> > let the function continue.
> >
> > * Appendix: how the issue was found *
>
> Thanks for the explanation, but I think I'll remove the appendix while
> applying.

The commit will have a link to this thread so if you don't mind,
I suggest to replace the full appendix with:

Issue was found with GCC -fanalyzer, please follow the link below
for details.

You can of course do the same for the m_can patch.


Yours sincerely,
Vincent Mailhol