[PATCH] irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()
Marc Zyngier
maz at kernel.org
Thu May 30 08:40:37 PDT 2024
Hi Hagar,
On Thu, 30 May 2024 11:57:13 +0100,
Hagar Hemdan <hagarhem at amazon.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 at amazon.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.
More information about the linux-arm-kernel
mailing list