Hi,
* Dan Carpenter <dan.carpen...@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_p...@topsec.com.cn>
> Signed-off-by: Dan Carpenter <dan.carpen...@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
