| 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
| ||
|
Message-ID: <20240531094544.GA3406@amazon.com>
Date: Fri, 31 May 2024 09:45:44 +0000
From: Hagar Hemdan <hagarhem@...zon.com>
To: Marc Zyngier <maz@...nel.org>
CC: Maximilian Heyne <mheyne@...zon.de>, Norbert Manthey <nmanthey@...zon.de>,
Thomas Gleixner <tglx@...utronix.de>, Eric Auger <eric.auger@...hat.com>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
<hagarhem@...zon.de>
Subject: Re: [PATCH] irqchip/gic-v3-its: Fix potential race condition in
its_vlpi_prop_update()
On Thu, May 30, 2024 at 04:40:37PM +0100, Marc Zyngier wrote:
> Hi Hagar,
>
> On Thu, 30 May 2024 11:57:13 +0100,
> Hagar Hemdan <hagarhem@...zon.com> wrote:
> >
> > Similar to commit 046b5054f566 ("irqchip/gic-v3-its: Lock VLPI map array
> > before translating it"), its_vlpi_prop_update() calls lpi_write_config()
> > which obtains the mapping information for a VLPI.
> > This should always be done with vlpi_lock for this device held. Otherwise,
> > its_vlpi_prop_update() could race with its_vlpi_unmap().
>
> Thanks for reporting this. Note that this issue is not the same as the
> one you refer to (what you have here is a total absence of locking,
> while 046b5054f566 fixed a call to get_vlpi_map() outside of an
> existing critical section).
>
> >
> > This bug was discovered and resolved using Coverity Static Analysis
> > Security Testing (SAST) by Synopsys, Inc.
>
> Should we get a scrolling banner for this kind of advertisements? ;-)
We either have to include that disclaimer, or cannot send fixes related
to that commercial tool :)
>
> >
> > Fixes: 015ec0386ab6 ("irqchip/gic-v3-its: Add VLPI configuration handling")
> > Signed-off-by: Hagar Hemdan <hagarhem@...zon.com>
> > ---
> > drivers/irqchip/irq-gic-v3-its.c | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> > index 40ebf1726393..ecaad1786345 100644
> > --- a/drivers/irqchip/irq-gic-v3-its.c
> > +++ b/drivers/irqchip/irq-gic-v3-its.c
> > @@ -1970,9 +1970,13 @@ static int its_vlpi_unmap(struct irq_data *d)
> > static int its_vlpi_prop_update(struct irq_data *d, struct its_cmd_info *info)
> > {
> > struct its_device *its_dev = irq_data_get_irq_chip_data(d);
> > + int ret = 0;
> >
> > - if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d))
> > - return -EINVAL;
> > + raw_spin_lock(&its_dev->event_map.vlpi_lock);
> > + if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> >
> > if (info->cmd_type == PROP_UPDATE_AND_INV_VLPI)
> > lpi_update_config(d, 0xff, info->config);
> > @@ -1980,7 +1984,9 @@ static int its_vlpi_prop_update(struct irq_data *d, struct its_cmd_info *info)
> > lpi_write_config(d, 0xff, info->config);
> > its_vlpi_set_doorbell(d, !!(info->config & LPI_PROP_ENABLED));
> >
> > - return 0;
> > +out:
> > + raw_spin_unlock(&its_dev->event_map.vlpi_lock);
> > + return ret;
> > }
> >
> > static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
>
> As it turns out, all the calls from its_irq_set_vcpu_affinity()
> require the same lock to be held. So instead of peppering the locking
> all over the place, we could (should?) hoist the locking into
> its_irq_set_vcpu_affinity() and avoid future bugs. It also results in
> a negative diffstat.
>
> Something like the hack below (compile-tested only), which I'm sure
> the "Coverity Static Analysis Security Testing (SAST) by Synopsys,
> Inc" will be able to verify...
>
> M.
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 40ebf1726393..abc1fb360ce4 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1851,23 +1851,18 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info)
> if (!info->map)
> return -EINVAL;
>
> - raw_spin_lock(&its_dev->event_map.vlpi_lock);
> -
> if (!its_dev->event_map.vm) {
> struct its_vlpi_map *maps;
>
> maps = kcalloc(its_dev->event_map.nr_lpis, sizeof(*maps),
> GFP_ATOMIC);
> - if (!maps) {
> - ret = -ENOMEM;
> - goto out;
> - }
> + if (!maps)
> + return -ENOMEM;
>
> its_dev->event_map.vm = info->map->vm;
> its_dev->event_map.vlpi_maps = maps;
> } else if (its_dev->event_map.vm != info->map->vm) {
> - ret = -EINVAL;
> - goto out;
> + return -EINVAL;
> }
>
> /* Get our private copy of the mapping information */
> @@ -1899,8 +1894,6 @@ static int its_vlpi_map(struct irq_data *d, struct its_cmd_info *info)
> its_dev->event_map.nr_vlpis++;
> }
>
> -out:
> - raw_spin_unlock(&its_dev->event_map.vlpi_lock);
> return ret;
> }
>
> @@ -1910,20 +1903,14 @@ static int its_vlpi_get(struct irq_data *d, struct its_cmd_info *info)
> struct its_vlpi_map *map;
> int ret = 0;
>
> - raw_spin_lock(&its_dev->event_map.vlpi_lock);
> -
> map = get_vlpi_map(d);
>
> - if (!its_dev->event_map.vm || !map) {
> - ret = -EINVAL;
> - goto out;
> - }
> + if (!its_dev->event_map.vm || !map)
> + return -EINVAL;
>
> /* Copy our mapping information to the incoming request */
> *info->map = *map;
>
> -out:
> - raw_spin_unlock(&its_dev->event_map.vlpi_lock);
> return ret;
> }
>
> @@ -1933,12 +1920,8 @@ static int its_vlpi_unmap(struct irq_data *d)
> u32 event = its_get_event_id(d);
> int ret = 0;
>
> - raw_spin_lock(&its_dev->event_map.vlpi_lock);
> -
> - if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d)) {
> - ret = -EINVAL;
> - goto out;
> - }
> + if (!its_dev->event_map.vm || !irqd_is_forwarded_to_vcpu(d))
> + return -EINVAL;
>
> /* Drop the virtual mapping */
> its_send_discard(its_dev, event);
> @@ -1962,8 +1945,6 @@ static int its_vlpi_unmap(struct irq_data *d)
> kfree(its_dev->event_map.vlpi_maps);
> }
>
> -out:
> - raw_spin_unlock(&its_dev->event_map.vlpi_lock);
> return ret;
> }
>
> @@ -1987,29 +1968,41 @@ static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info)
> {
> struct its_device *its_dev = irq_data_get_irq_chip_data(d);
> struct its_cmd_info *info = vcpu_info;
> + int ret;
>
> /* Need a v4 ITS */
> if (!is_v4(its_dev->its))
> return -EINVAL;
>
> + raw_spin_lock(&its_dev->event_map.vlpi_lock);
> +
> /* Unmap request? */
> - if (!info)
> - return its_vlpi_unmap(d);
> + if (!info) {
> + ret = its_vlpi_unmap(d);
> + goto out;
> + }
>
> switch (info->cmd_type) {
> case MAP_VLPI:
> - return its_vlpi_map(d, info);
> + ret = its_vlpi_map(d, info);
> + break;
>
> case GET_VLPI:
> - return its_vlpi_get(d, info);
> + ret = its_vlpi_get(d, info);
> + break;
>
> case PROP_UPDATE_VLPI:
> case PROP_UPDATE_AND_INV_VLPI:
> - return its_vlpi_prop_update(d, info);
> + ret = its_vlpi_prop_update(d, info);
> + break;
>
> default:
> - return -EINVAL;
> + ret = -EINVAL;
> }
> +
> +out:
> + raw_spin_unlock(&its_dev->event_map.vlpi_lock);
> + return ret;
> }
>
> static struct irq_chip its_irq_chip = {
>
> --
> Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists