| 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: <Z35q0vMEvt7yYHBx@e129823.arm.com>
Date: Wed, 8 Jan 2025 12:08:50 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Suzuki K Poulose <suzuki.poulose@....com>
Cc: mike.leach@...aro.org, james.clark@...aro.org,
alexander.shishkin@...ux.intel.com, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] coresight: prevent deactivate active config while
enable the config
Hi Suzuki,
> On 07/01/2025 13:01, Yeoreum Yun wrote:
> > Hi Suzuki,
> >
> > > Hi Levi
> > >
> > > On 23/12/2024 18:53, Yeoreum Yun wrote:
> > > > While enable active config via cscfg_csdev_enable_active_config(),
> > > > active config could be deactivated via configfs' sysfs interface.
> > > > This could make UAF issue in below scenario:
> > > >
> > > > CPU0 CPU1
> > > > (sysfs enable) load module
> > > > cscfg_load_config_sets()
> > > > activate config. // sysfs
> > > > (sys_active_cnt == 1)
> > > > ...
> > > > cscfg_csdev_enable_active_config()
> > > > lock(csdev->cscfg_csdev_lock)
> > > > // here load config activate by CPU1
> > > > unlock(csdev->cscfg_csdev_lock)
> > > >
> > > > deactivate config // sysfs
> > > > (sys_activec_cnt == 0)
> > > > cscfg_unload_config_sets()
> > > > unload module
> > > >
> > > > // access to config_desc which freed
> > > > // while unloading module.
> > > > cfs_csdev_enable_config
> > > >
> > > > To address this, introduce sys_enable_cnt in cscfg_mgr to prevent
> > > > deactivate while there is enabled configuration.
> > >
> > > Thanks for the finding the problem and the detailed description + patch. I
> > > have some concerns on the fix, please find it below.
> > >
> > > >
> > >
> > >
> > > So we have 3 atomic counters now !
> > > cscfg_mgr->sys_active_cnt // Global count
> > > config->active_cnt // Per config count,
> > >
> > > And another one which this one introduces.
> > >
> > > cscfg_mgr->sys_enable_cnt // ?
> > >
> > >
> > > And config->active_cnt is always ever 0 or 1. i.e., it is not really a
> > > reference counter at the moment but it indicates whether it is active or
> > > not. Could we not use that for tracking the references on the specific
> > > config ?
> > >
> > > i.e., every time we "enable_active_config" atomic_inc(config->active_cnt)
> > >
> > > and disable_active_config() always decrements the config. These could be
> > > wrapped in cscfg_get() cscfg_put() which would, inc/dec the refcounts
> > > and also drop the "module" reference when the active_cnt == 0
> >
> > This action is done via _cscfg_activate_config() already but its
> > activation is done via "sysfs".
> > and the checking active_cnt, I think it would increase lots of complex.
>
> I don't understand. We have this today :
>
> cscfg_config_desc which is getting de-activated. This has reference to
> the module (owner). If someone is using this config_desc in running session
> (be it perf or sysfg), it must be refcounted. As such I don't
> see that the cscfg is refcounted anywhere. (The active_cnt indicates if this
> has been activated, but not used in a session). If we have a refcount on the
> "cscfg_config_desc" for each active session, we could
> prevent/delay unloading the module until the last one drops.
>
>
>
>
> Something like this is what I was checking ?
Thanks for your code. I understand what you mean now.
But I think below code would need to add together:
diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c b/drivers/hwtracing/coresight/coresight-syscfg.c
index 11138a9762b0..fe1adcf45f06 100644
--- a/drivers/hwtracing/coresight/coresight-syscfg.c
+++ b/drivers/hwtracing/coresight/coresight-syscfg.c
@@ -391,14 +391,17 @@ static void cscfg_owner_put(struct cscfg_load_owner_info *owner_info)
static void cscfg_remove_owned_csdev_configs(struct coresight_device *csdev, void *load_owner)
{
struct cscfg_config_csdev *config_csdev, *tmp;
+ unsigned long flags;
if (list_empty(&csdev->config_csdev_list))
return;
+ spin_lock_irqsave(&csdev->cscfg_csdv_lock, flags);
list_for_each_entry_safe(config_csdev, tmp, &csdev->config_csdev_list, node) {
if (config_csdev->config_desc->load_owner == load_owner)
list_del(&config_csdev->node);
}
+ spin_unlock_irqrestore(&csdev->cscfg_csdv_lock, flags);
}
Otherwise, If atomic_inc_not_zero(&config_desc->active_cnt) failed
and cscfg_remove_owned_csdev_configs() is called as part of unloading module
before list_next_entry(), it could see LIST_POISON1.
Do you mind to send patch again with your suggestion including above
patch too?
Thanks.
>
>
> coresight: cscfg: Hold refcount on the config for active
> sessions
>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
> ---
> .../hwtracing/coresight/coresight-config.h | 2 +-
> .../hwtracing/coresight/coresight-syscfg.c | 24 +++++++++++++------
> 2 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-config.h
> b/drivers/hwtracing/coresight/coresight-config.h
> index 6ba013975741..84cdde6f0e4d 100644
> --- a/drivers/hwtracing/coresight/coresight-config.h
> +++ b/drivers/hwtracing/coresight/coresight-config.h
> @@ -228,7 +228,7 @@ struct cscfg_feature_csdev {
> * @feats_csdev:references to the device features to enable.
> */
> struct cscfg_config_csdev {
> - const struct cscfg_config_desc *config_desc;
> + struct cscfg_config_desc *config_desc;
> struct coresight_device *csdev;
> bool enabled;
> struct list_head node;
> diff --git a/drivers/hwtracing/coresight/coresight-syscfg.c
> b/drivers/hwtracing/coresight/coresight-syscfg.c
> index 11138a9762b0..53baeaaf907f 100644
> --- a/drivers/hwtracing/coresight/coresight-syscfg.c
> +++ b/drivers/hwtracing/coresight/coresight-syscfg.c
> @@ -914,15 +914,20 @@ static int _cscfg_activate_config(unsigned long
> cfg_hash)
> return err;
> }
>
> +static void cscfg_config_desc_put(struct cscfg_config_desc *config_desc)
> +{
> + if (!atomic_dec_return(&config_desc->active_cnt))
> + cscfg_owner_put(config_desc->load_owner);
> +}
> +
> static void _cscfg_deactivate_config(unsigned long cfg_hash)
> {
> struct cscfg_config_desc *config_desc;
>
> list_for_each_entry(config_desc, &cscfg_mgr->config_desc_list, item) {
> if ((unsigned long)config_desc->event_ea->var == cfg_hash) {
> - atomic_dec(&config_desc->active_cnt);
> atomic_dec(&cscfg_mgr->sys_active_cnt);
> - cscfg_owner_put(config_desc->load_owner);
> + cscfg_config_desc_put(config_desc);
> dev_dbg(cscfg_device(), "Deactivate config %s.\n", config_desc->name);
> break;
> }
> @@ -1047,7 +1052,7 @@ int cscfg_csdev_enable_active_config(struct
> coresight_device *csdev,
> unsigned long cfg_hash, int preset)
> {
> struct cscfg_config_csdev *config_csdev_active = NULL, *config_csdev_item;
> - const struct cscfg_config_desc *config_desc;
> + struct cscfg_config_desc *config_desc;
> unsigned long flags;
> int err = 0;
>
> @@ -1062,8 +1067,8 @@ int cscfg_csdev_enable_active_config(struct
> coresight_device *csdev,
> spin_lock_irqsave(&csdev->cscfg_csdev_lock, flags);
> list_for_each_entry(config_csdev_item, &csdev->config_csdev_list, node) {
> config_desc = config_csdev_item->config_desc;
> - if ((atomic_read(&config_desc->active_cnt)) &&
> - ((unsigned long)config_desc->event_ea->var == cfg_hash)) {
> + if ((unsigned long)config_desc->event_ea->var == cfg_hash &&
> + atomic_inc_not_zero(&config_desc->active_cnt)) {
> config_csdev_active = config_csdev_item;
> csdev->active_cscfg_ctxt = (void *)config_csdev_active;
> break;
> @@ -1091,12 +1096,15 @@ int cscfg_csdev_enable_active_config(struct
> coresight_device *csdev,
> * Set enabled if OK, err if not.
> */
> spin_lock_irqsave(&csdev->cscfg_csdev_lock, flags);
> - if (csdev->active_cscfg_ctxt)
> + if (csdev->active_cscfg_ctxt == config_csdev_active)
> config_csdev_active->enabled = true;
> else
> err = -EBUSY;
> spin_unlock_irqrestore(&csdev->cscfg_csdev_lock, flags);
> }
> + if (err)
> + cscfg_config_desc_put(config_desc);
> +
> }
> return err;
> }
> @@ -1136,8 +1144,10 @@ void cscfg_csdev_disable_active_config(struct
> coresight_device *csdev)
> spin_unlock_irqrestore(&csdev->cscfg_csdev_lock, flags);
>
> /* true if there was an enabled active config */
> - if (config_csdev)
> + if (config_csdev) {
> cscfg_csdev_disable_config(config_csdev);
> + cscfg_config_desc_put(config_csdev->config_desc);
> + }
> }
> EXPORT_SYMBOL_GPL(cscfg_csdev_disable_active_config);
>
> --
>
>
>
>
>
>
>
> > because, if so, it should iterate all config in each csdev.
> > So, I believe it is the reason why the activation and module_cnt get via "sysfs"
> > to prevent iterating every config in csdev when config unload.
> >
> > although, active_cnt in each config added to list in csdev be 0 or 1,
> > the module could be >= 1 (by sum of active_cnt which have the same
> > module owner). So I'm skeptical to use active_cnt like "reference cnt"
> > and That's why I decide to use "sys_enable_cnt"
> > >
> > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@....com>
> > > > ---
> > > > from v1 to v2:
> > > > - modify commit message.
> > > > ---
> > > > .../hwtracing/coresight/coresight-etm4x-core.c | 3 +++
> > > > drivers/hwtracing/coresight/coresight-syscfg.c | 18 ++++++++++++++++--
> > > > drivers/hwtracing/coresight/coresight-syscfg.h | 2 ++
> > > > 3 files changed, 21 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > > index 86893115df17..6218ef40acbc 100644
> > > > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> > > > @@ -986,6 +986,9 @@ static void etm4_disable_sysfs(struct coresight_device *csdev)
> > > > smp_call_function_single(drvdata->cpu, etm4_disable_hw, drvdata, 1);
> > > >
> > > > raw_spin_unlock(&drvdata->spinlock);
> > > > +
> > > > + cscfg_csdev_disable_active_config(csdev);
> > >
> > > This looks like a separate "fix" from what you are trying to address. Please
> > > could split this ?
> >
> > I don't think so, because without this calling, the "sys_enable_cnt"
> > never down, It makes error.
>
> My point is, we need to "disable_active_config" irrespective of this race,
> in the sysfs path. So this should be a fix apart from fixing the race.
>
> Suzuki
>
>
>
> >
> > > Also, would like to hear what Mike has to say about this change.
> >
> > IIRC, I followed his suggestion.
> >
> > Thanks!
> >
>
Powered by blists - more mailing lists