Re: [PATCH 2/4] tty: n_gsm: Prevent a potential use after free

[Tony Lindgren <tony@atomide.com>]

Hi,

* Dan Carpenter <dan.carpenter@oracle.com> [180426 05:55]:
> We're freeing the gsm->dlci[] array elements but leaving the freed
> pointers hanging around.
> 
> My concern here is if we use the ioctl to change the config, it triggers
> a restart in gsmld_config().  In that case, we would only reset the
> first ->dlci[0] element and not the others so it does look to me like a
> possible use after free.
> 
> Reported-by: Sun Peng <sun_peng@topsec.com.cn>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index cc7f68814200..1f2fd9e76fe0 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -2075,9 +2075,11 @@ static void gsm_cleanup_mux(struct gsm_mux *gsm)
>  
>  	/* Free up any link layer users */
>  	mutex_lock(&gsm->mutex);
> -	for (i = 0; i < NUM_DLCI; i++)
> +	for (i = 0; i < NUM_DLCI; i++) {
>  		if (gsm->dlci[i])
>  			gsm_dlci_release(gsm->dlci[i]);
> +		gsm->dlci[i] = NULL;
> +	}
>  	mutex_unlock(&gsm->mutex);
>  	/* Now wipe the queues */
>  	list_for_each_entry_safe(txq, ntxq, &gsm->tx_list, list)

This one causes the following oops for me on closing n_gsm:

Unable to handle kernel NULL pointer dereference at virtual address 0000025c
...
(refcount_sub_and_test) from [<c057e424>] (refcount_dec_and_test+0x18/0x1c)
(refcount_dec_and_test) from [<c06378b8>] (tty_port_put+0x24/0x9c)
(tty_port_put) from [<bf8c9614>] (gsmtty_cleanup+0x2c/0x48 [n_gsm])
(gsmtty_cleanup [n_gsm]) from [<c062e0d4>] (release_one_tty+0x3c/0xa0)
(release_one_tty) from [<c01622b0>] (process_one_work+0x2ac/0x858)

Regards,

Tony