[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<GV1PR08MB10521BB7C93822F5124F2D66EFBD22@GV1PR08MB10521.eurprd08.prod.outlook.com>
Date: Fri, 14 Mar 2025 15:24:58 +0000
From: Yeo Reum Yun <YeoReum.Yun@....com>
To: Mike Leach <mike.leach@...aro.org>
CC: Suzuki Poulose <Suzuki.Poulose@....com>, "james.clark@...aro.org"
<james.clark@...aro.org>, "alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>, "coresight@...ts.linaro.org"
<coresight@...ts.linaro.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/1] coresight: prevent deactivate active config while
enabling the config
Hi, Mike.
> > static void cscfg_remove_owned_csdev_features(struct coresight_device *csdev, void *load_owner)
> > @@ -867,6 +870,28 @@ void cscfg_csdev_reset_feats(struct coresight_device *csdev)
> > }
> > EXPORT_SYMBOL_GPL(cscfg_csdev_reset_feats);
> >
> > +static bool cscfg_config_desc_get(struct cscfg_config_desc *config_desc, bool enable)
> > +{
> > + if (enable)
> > + return atomic_inc_not_zero(&config_desc->active_cnt);
> > +
>
> Not sure why we have an "enable" parameter here - it completely
> changes the meaning of the function - with no comment at the start.
Sorry. But what I intended is to distinguish
- activation of config
- enable of activated config.
Because, current coresight doesn't grab the module reference on enable of activate config,
But It grabs that reference only in activation.
That's why I used to "enable" parameter to distinguish this
while I integrate with module_owner count.
> > 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 +1066,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 +1081,8 @@ int cscfg_csdev_enable_active_config(struct coresight_device *csdev,
> > raw_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) &&
> > + cscfg_config_desc_get(config_desc, true)) {
> >
> This obfuscates the logic of the comparisons without good reason. With
> the true parameter, the function does no "get" operation but just
> replicates the logic being replaced - checking the active_cnt is
> non-zero.
>
> Restore this to the original logic to make it readable again
It's not a replicates of comparsion logic, but if true,
It get the reference of active_cnt but not get module reference.
The fundemental fault in the UAF becase of just "atomic_read()"
so, it should hold reference in here.
So, If you think the cscfg_config_desc_get()'s parameter makes obfuscation,
I think there're two way to modfiy.
1. cscfg_config_desc_get()/put() always grab/drop the module count.
2. remove cscfg_config_desc_get()/put() but just use atomic_XXX(&active_cnt) only
with cscfg_owner_get()/put()
Any thougt?
Thanks!
Powered by blists - more mailing lists