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: <20240531045857.GA14712@amazon.com>
Date: Fri, 31 May 2024 04:58:57 +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 Marc,

yes, you are right. The lock should be moved to
its_irq_set_vcpu_affinity(). I will update the patch and the commit
message in rev2.

Thanks,
Hagar

> 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? ;-)
> 
> > 
> > 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.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ