Re: [PATCH] gpio: sloppy-logic-analyzer: Fix memory leak in gpio_la_poll_probe()

[Abdun Nihaal]

Hello,

On Sun, Jul 12, 2026 at 11:27:19AM +0200, Wolfram Sang wrote:
> On Fri, Jul 10, 2026 at 12:18:36PM +0530, Abdun Nihaal wrote:
> 
> > The memory allocated for priv->blob.data is not freed in the error paths
> > that follow the fops_buf_size_set() call in gpio_la_poll_probe(), as
> > well as in the remove function.
> 
> There is no memory allocated at that time. Hmm, maybe I should add a
> comment explaining it.
> 

What I meant was that after the priv->blob.data is allocated
successfully in fops_buf_size_set(), the subsequent error returns in
gpio_la_poll_probe() don't free the buffer, but directly return (since
all the other allocations are device managed). And so I feel that there
is a leak possible here.

    fops_buf_size_set(priv, GPIO_LA_DEFAULT_BUF_SIZE);
    // After a successful allocation in fops_buf_size_set()

    priv->descs = devm_gpiod_get_array(dev, "probe", GPIOD_IN);
    if (IS_ERR(priv->descs))
    	return PTR_ERR(priv->descs);    // Leaks here

    /* artificial limit to keep 1 byte per sample for now */
    if (priv->descs->ndescs > GPIO_LA_MAX_PROBES)
    	return -EFBIG;                  // Leaks here

    // And leaks in all subsequent error paths

If you prefer, I can remove the return code check for theh
fops_buf_size_set() call and just have the devm_add_action_or_reset()
part for releasing.

Also I don't see the buffer getting freed in the remove function
gpio_la_poll_remove(), unless it is implicitly freed by
debugfs_remove_recursive().

We are using a prototype static analysis tool based on LLVM, which we
are building for a research project.

Regards,
Nihaal