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;
IronPort-SDR: 2VtzdZOvhL4iSaU9dh16WtFzCb+IdjinHHZX6qvsAGudmSAyEpR3Do2ppPU34Lw7fs0QU5AFN8
 0D993AKMHa35J28y08MrMTOGcy1t6nAXodPluHwP12Zxo8lY10zUiXptc9UcJJnJbEeU88BZ9k
 ml1sHeA8LQ7iPDAtsqXubNxnsG4x3SX2ldo5s57Qj1hS2iaqyH+55dlaaw9abPK/9pZAcFtqmb
 QecVf3VqrTNGXbbdPA6ePvMhprHCW5ZC8+JJUrbRScWtC74zryFXA6ogKkYFtFstd4l7EyrsN0
 8qY=
From:   Niklas Cassel <Niklas.Cassel@wdc.com>
To:     =?iso-8859-1?Q?Javier_Gonz=E1lez?= <javier@javigon.com>
CC:     Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
        Christoph Hellwig <hch@lst.de>,
        Sagi Grimberg <sagi@grimberg.me>,
        Igor Konopko <igor.j.konopko@intel.com>,
        =?iso-8859-1?Q?Matias_Bj=F8rling?= <mb@lightnvm.io>,
        Jens Axboe <axboe@kernel.dk>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nvme: prevent double free in nvme_alloc_ns() error
 handling
Thread-Topic: [PATCH] nvme: prevent double free in nvme_alloc_ns() error
 handling
Thread-Index: AQHWHJBF5J2JgQiUdUSwnibdYIeruaiNQxmAgAAFd4A=
Date:   Mon, 27 Apr 2020 18:22:46 +0000
Message-ID: <20200427182245.GA547726@localhost.localdomain>
References: <20200427123443.520469-1-niklas.cassel@wdc.com>
 <20200427180311.nssquibbak5ib4oo@mpHalley.localdomain>
In-Reply-To: <20200427180311.nssquibbak5ib4oo@mpHalley.localdomain>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2C0B76D1975B0F479825BFE0FF922E9B@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 271aa722-a0fb-4a2e-994e-08d7ead7fc25
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 18:22:46.3533
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: umv3FiSPn02KxF3aekLDJt0bYvlMykg64oxE60H8mTcu8JMyyOgviCe/9qIUQiH3Ey7CgSbfg8A56MyH1GO0og==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB3862
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Apr 27, 2020 at 08:03:11PM +0200, Javier Gonz=E1lez wrote:
> On 27.04.2020 14:34, Niklas Cassel wrote:
> > When jumping to the out_put_disk label, we will call put_disk(), which =
will
> > trigger a call to disk_release(), which calls blk_put_queue().
> >=20
> > Later in the cleanup code, we do blk_cleanup_queue(), which will also c=
all
> > blk_put_queue().
> >=20
> > Putting the queue twice is incorrect, and will generate a KASAN splat.
> >=20
> > Set the disk->queue pointer to NULL, before calling put_disk(), so that=
 the
> > first call to blk_put_queue() will not free the queue.
> >=20
> > The second call to blk_put_queue() uses another pointer to the same que=
ue,
> > so this call will still free the queue.
> >=20
> > Fixes: 85136c010285 ("lightnvm: simplify geometry enumeration")
> > Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> > ---
> > drivers/nvme/host/core.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >=20
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index 91c1bd659947..f2adea96b04c 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -3642,6 +3642,8 @@ static void nvme_alloc_ns(struct nvme_ctrl *ctrl,=
 unsigned nsid)
> >=20
> >       return;
> >  out_put_disk:
> > +      /* prevent double queue cleanup */
> > +      ns->disk->queue =3D NULL;
> >       put_disk(ns->disk);
> >  out_unlink_ns:
> >       mutex_lock(&ctrl->subsys->lock);
> > --
> > 2.25.3
> >=20
> What about delaying the assignment of ns->disk?
>=20
> diff --git i/drivers/nvme/host/core.c w/drivers/nvme/host/core.c
> index a4d8c90ee7cc..6da4a9ced945 100644
> --- i/drivers/nvme/host/core.c
> +++ w/drivers/nvme/host/core.c
> @@ -3541,7 +3541,6 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl, un=
signed nsid)
>         disk->queue =3D ns->queue;
>         disk->flags =3D flags;
>         memcpy(disk->disk_name, disk_name, DISK_NAME_LEN);
> -       ns->disk =3D disk;
>=20
>         __nvme_revalidate_disk(disk, id);
>=20
> @@ -3553,6 +3552,8 @@ static int nvme_alloc_ns(struct nvme_ctrl *ctrl, un=
signed nsid)
>                 }
>         }
>=20
> +       ns->disk =3D disk;
> +

Hello Javier!


The only case where we jump to the out_put_disk label, is if the
nvme_nvm_register() call failed.

In that case, we want to undo the alloc_disk_node() operation, i.e.,
decrease the refcount.

If we don't set "ns->disk =3D disk;" before the call to nvme_nvm_register()=
,
then, if register fails, and we jump to the put_disk(ns->disk) label,
ns->disk will be NULL, so the recount will not be decreased, so I assume
that this memory would then be a memory leak.


I think that the problem is that the block functions are a bit messy.
Most drivers seem to do blk_cleanup_queue() first and then do put_disk(),
but some drivers do it in the opposite way, so I think that we might have
some more use-after-free bugs in some of these drivers that do it in the
opposite way.


Kind regards,
Niklas

>         down_write(&ctrl->namespaces_rwsem);
>         list_add_tail(&ns->list, &ctrl->namespaces);
>         up_write(&ctrl->namespaces_rwsem);
>=20
>=20
> Javier=