Re: [v3] nbd: fix potential NULL pointer fault in nbd_genl_disconnect

[Sun Ke]

å 2020/2/12 10:00, sunke (E) åé:
> å 2020/2/12 0:39, Mike Christie åé:
> > On 02/10/2020 10:12 PM, sunke (E) wrote:
> > > å 2020/2/11 1:05, Mike Christie åé:
> > > > On 02/10/2020 01:32 AM, Sun Ke wrote:
> > > > > Open /dev/nbdX first, the config_refs will be 1 and
> > > > > the pointers in nbd_device are still null. Disconnect
> > > > > /dev/nbdX, then reference a null recv_workq. The
> > > > > protection by config_refs in nbd_genl_disconnect is useless.
> > > > >
> > > > > To fix it, just add a check for a non null task_recv in
> > > > > nbd_genl_disconnect.
> > > > >
> > > > > Signed-off-by: Sun Ke <sunke32@xxxxxxxxxx>
> > > > > ---
> > > > > v1 -> v2:
> > > > > Add an omitted mutex_unlock.
> > > > >
> > > > > v2 -> v3:
> > > > > Add nbd->config_lock, suggested by Josef.
> > > > > ---
> > > > > ÂÂ drivers/block/nbd.c | 8 ++++++++
> > > > > ÂÂ 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> > > > > index b4607dd96185..870b3fd0c101 100644
> > > > > --- a/drivers/block/nbd.c
> > > > > +++ b/drivers/block/nbd.c
> > > > > @@ -2008,12 +2008,20 @@ static int nbd_genl_disconnect(struct sk_buff
> > > > > *skb, struct genl_info *info)
> > > > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ index);
> > > > > ÂÂÂÂÂÂÂÂÂÂ return -EINVAL;
> > > > > ÂÂÂÂÂÂ }
> > > > > +ÂÂÂ mutex_lock(&nbd->config_lock);
> > > > > ÂÂÂÂÂÂ if (!refcount_inc_not_zero(&nbd->refs)) {
> > > > > +ÂÂÂÂÂÂÂ mutex_unlock(&nbd->config_lock);
> > > > > ÂÂÂÂÂÂÂÂÂÂ mutex_unlock(&nbd_index_mutex);
> > > > > ÂÂÂÂÂÂÂÂÂÂ printk(KERN_ERR "nbd: device at index %d is going down\n",
> > > > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ index);
> > > > > ÂÂÂÂÂÂÂÂÂÂ return -EINVAL;
> > > > > ÂÂÂÂÂÂ }
> > > > > +ÂÂÂ if (!nbd->recv_workq) {
> > > > > +ÂÂÂÂÂÂÂ mutex_unlock(&nbd->config_lock);
> > > > > +ÂÂÂÂÂÂÂ mutex_unlock(&nbd_index_mutex);
> > > > > +ÂÂÂÂÂÂÂ return -EINVAL;
> > > > > +ÂÂÂ }
> > > > > +ÂÂÂ mutex_unlock(&nbd->config_lock);
> > > > > ÂÂÂÂÂÂ mutex_unlock(&nbd_index_mutex);
> > > > > ÂÂÂÂÂÂ if (!refcount_inc_not_zero(&nbd->config_refs)) {
> > > > > ÂÂÂÂÂÂÂÂÂÂ nbd_put(nbd);
> > > >
> > > > With my other patch then we will not need this right? It handles your
> > > > case by just being integrated with the existing checks in:
> > > >
> > > > nbd_disconnect_and_put->nbd_clear_sock->sock_shutdown
> > > >
> > > > ...
> > > >
> > > > static void sock_shutdown(struct nbd_device *nbd)
> > > > {
> > > >
> > > > ....
> > > >
> > > > ÂÂÂÂÂÂÂÂÂ if (config->num_connections == 0)
> > > > ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ return;
> > > >
> > > >
> > > > num_connections is zero for your case since we never did a
> > > > nbd_genl_disconnect so we would return here.
> > > >
> > > >
> > > > .
> > > Hi Mike
> > >
> > > Your point is not right totally.
> > >
> > > Yes, config->num_connections is 0 and will return in sock_shutdown. Then
> > > it will back to nbd_disconnect_and_put and do flush_workqueue
> > > (nbd->recv_workq).
> > >
> > > nbd_disconnect_and_put
> > > ÂÂÂÂ ->nbd_clear_sock
> > > ÂÂÂÂÂÂÂÂ ->sock_shutdown
> > > ÂÂÂÂ ->flush_workqueue
> >
> > My patch removed that extra flush_workqueue in nbd_disconnect_and_put.
> >
> > The idea of the patch was to move the flush calls to when we do
> > sock_shutdown in the config (connect, disconnect, clear sock) code
> > paths, because that is the time we know we will need to kill the recv
> > workers and wait for them to complete so we know they are not still
> > running when userspace does a new config operation.
> Yes, I see.

Hi Mike

Have you sent your patch?