linux-kernel - Re: [bug] NULL pointer deref after 3f6634d997db ("iommu: Use right way to retrieve iommu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAASaF6zc=6Mxo6uq1m7OMkXGPHmqeb=92uE8uERo9ze-GLndfg@mail.gmail.com>
Date:   Wed, 4 May 2022 14:08:43 +0200
From:   Jan Stancek <jstancek@...hat.com>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Lu Baolu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        Jason Gunthorpe <jgg@...dia.com>,
        Christoph Hellwig <hch@...radead.org>,
        Ben Skeggs <bskeggs@...hat.com>,
        Kevin Tian <kevin.tian@...el.com>,
        Ashok Raj <ashok.raj@...el.com>, Will Deacon <will@...nel.org>,
        Alex Williamson <alex.williamson@...hat.com>,
        Eric Auger <eric.auger@...hat.com>,
        Liu Yi L <yi.l.liu@...el.com>,
        Jacob jun Pan <jacob.jun.pan@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        iommu@...ts.linux-foundation.org,
        lkml <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@....de>,
        Bruno Goncalves <bgoncalv@...hat.com>
Subject: Re: [bug] NULL pointer deref after 3f6634d997db ("iommu: Use right
 way to retrieve iommu_ops")

On Wed, May 4, 2022 at 1:14 PM Robin Murphy <robin.murphy@....com> wrote:
>
> On 2022-05-04 08:53, Jan Stancek wrote:
> [...]
> > Hi,
> >
> > I'm getting panics after hunk above was applied in this patch
> > on ppc64le KVM guest, dev->iommu is NULL.
>
> Oof, this can probably be hit with vfio-noiommu too, and by the look of
> things, `echo auto > /sys/kernel/iommu_groups/0/type` would likely blow
> up as well. Does the patch below work for you?

Thanks for quick reply. Yes, it does.

# cat /sys/kernel/iommu_groups/0/reserved_regions
# echo auto > /sys/kernel/iommu_groups/0/type
-bash: echo: write error: Invalid argument

Tested-by: Jan Stancek <jstancek@...hat.com>

>
> Thanks,
> Robin.
>
> ----->8-----
>  From abf0a38563bb2922a849e235d33d342170b5bc90 Mon Sep 17 00:00:00 2001
> Message-Id: <abf0a38563bb2922a849e235d33d342170b5bc90.1651662442.git.robin.murphy@....com>
> From: Robin Murphy <robin.murphy@....com>
> Date: Wed, 4 May 2022 11:53:20 +0100
> Subject: [PATCH] iommu: Make sysfs robust for non-API groups
>
> Groups created by VFIO backends outside the core IOMMU API should never
> be passed directly into the API itself, however they still expose their
> standard sysfs attributes, so we can still stumble across them that way.
> Take care to consider those cases before jumping into our normal
> assumptions of a fully-initialised core API group.
>
> Fixes: 3f6634d997db ("iommu: Use right way to retrieve iommu_ops")
> Reported-by: Jan Stancek <jstancek@...hat.com>
> Signed-off-by: Robin Murphy <robin.murphy@....com>
> ---
>   drivers/iommu/iommu.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 29906bc16371..41ea2deaee03 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -510,6 +510,13 @@ int iommu_get_group_resv_regions(struct iommu_group *group,
>         list_for_each_entry(device, &group->devices, list) {
>                 struct list_head dev_resv_regions;
>
> +               /*
> +                * Non-API groups still expose reserved_regions in sysfs,
> +                * so filter out calls that get here that way.
> +                */
> +               if (!device->dev->iommu)
> +                       break;
> +
>                 INIT_LIST_HEAD(&dev_resv_regions);
>                 iommu_get_resv_regions(device->dev, &dev_resv_regions);
>                 ret = iommu_insert_device_resv_regions(&dev_resv_regions, head);
> @@ -2977,7 +2984,7 @@ static ssize_t iommu_group_store_type(struct iommu_group *group,
>         if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO))
>                 return -EACCES;
>
> -       if (WARN_ON(!group))
> +       if (WARN_ON(!group) || !group->default_domain)
>                 return -EINVAL;
>
>         if (sysfs_streq(buf, "identity"))
> --
> 2.35.3.dirty
>