All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
@ 2019-12-28  6:43 ` qiwuchen55
  0 siblings, 0 replies; 12+ messages in thread
From: qiwuchen55 @ 2019-12-28  6:43 UTC (permalink / raw)
  To: kgene, krzk, rjw, viresh.kumar
  Cc: linux-arm-kernel, linux-samsung-soc, linux-pm, linux-kernel, chenqiwu

From: chenqiwu <chenqiwu@xiaomi.com>

There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
the cpufreq policy of cpu0 has been released before using it. So we should
make a judgement to avoid it.

Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
---
 drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
 drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
index 1069103..0f576ba 100644
--- a/drivers/cpufreq/s3c2416-cpufreq.c
+++ b/drivers/cpufreq/s3c2416-cpufreq.c
@@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
 {
 	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
 	int ret;
+	struct cpufreq_policy policy;
 
 	mutex_lock(&cpufreq_lock);
 
@@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
 	 */
 	if (s3c_freq->is_dvs) {
 		pr_debug("cpufreq: leave dvs on reboot\n");
-		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
+
+		memset(&policy, 0, sizeof(policy));
+		ret = cpufreq_get_policy(&policy, 0);
+		if (ret < 0) {
+			pr_debug("cpufreq: get no policy for cpu0\n");
+			return NOTIFY_BAD;
+		}
+
+		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
 		if (ret < 0)
 			return NOTIFY_BAD;
 	}
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
index 5d10030..d99b4b1 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
 						 unsigned long event, void *ptr)
 {
 	int ret;
+	struct cpufreq_policy *policy;
 
-	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
+	policy = cpufreq_cpu_get(0);
+	if (!policy) {
+		pr_debug("cpufreq: get no policy for cpu0\n");
+		return NOTIFY_BAD;
+	}
+
+	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
+	cpufreq_cpu_put(policy);
 	if (ret < 0)
 		return NOTIFY_BAD;
 
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
@ 2019-12-28  6:43 ` qiwuchen55
  0 siblings, 0 replies; 12+ messages in thread
From: qiwuchen55 @ 2019-12-28  6:43 UTC (permalink / raw)
  To: kgene, krzk, rjw, viresh.kumar
  Cc: linux-samsung-soc, chenqiwu, linux-kernel, linux-arm-kernel, linux-pm

From: chenqiwu <chenqiwu@xiaomi.com>

There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
the cpufreq policy of cpu0 has been released before using it. So we should
make a judgement to avoid it.

Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
---
 drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
 drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
index 1069103..0f576ba 100644
--- a/drivers/cpufreq/s3c2416-cpufreq.c
+++ b/drivers/cpufreq/s3c2416-cpufreq.c
@@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
 {
 	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
 	int ret;
+	struct cpufreq_policy policy;
 
 	mutex_lock(&cpufreq_lock);
 
@@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
 	 */
 	if (s3c_freq->is_dvs) {
 		pr_debug("cpufreq: leave dvs on reboot\n");
-		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
+
+		memset(&policy, 0, sizeof(policy));
+		ret = cpufreq_get_policy(&policy, 0);
+		if (ret < 0) {
+			pr_debug("cpufreq: get no policy for cpu0\n");
+			return NOTIFY_BAD;
+		}
+
+		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
 		if (ret < 0)
 			return NOTIFY_BAD;
 	}
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
index 5d10030..d99b4b1 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
 						 unsigned long event, void *ptr)
 {
 	int ret;
+	struct cpufreq_policy *policy;
 
-	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
+	policy = cpufreq_cpu_get(0);
+	if (!policy) {
+		pr_debug("cpufreq: get no policy for cpu0\n");
+		return NOTIFY_BAD;
+	}
+
+	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
+	cpufreq_cpu_put(policy);
 	if (ret < 0)
 		return NOTIFY_BAD;
 
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
  2019-12-28  6:43 ` qiwuchen55
@ 2020-01-06  5:48   ` Viresh Kumar
  -1 siblings, 0 replies; 12+ messages in thread
From: Viresh Kumar @ 2020-01-06  5:48 UTC (permalink / raw)
  To: qiwuchen55
  Cc: kgene, krzk, rjw, linux-arm-kernel, linux-samsung-soc, linux-pm,
	linux-kernel, chenqiwu

On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> From: chenqiwu <chenqiwu@xiaomi.com>
> 
> There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> the cpufreq policy of cpu0 has been released before using it. So we should
> make a judgement to avoid it.

There is no UAF problem here, but that we do cpufreq_cpu_get() with a
corresponding cpufreq_cpu_put().

> Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> ---
>  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
>  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> index 1069103..0f576ba 100644
> --- a/drivers/cpufreq/s3c2416-cpufreq.c
> +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
>  {
>  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
>  	int ret;
> +	struct cpufreq_policy policy;
>  
>  	mutex_lock(&cpufreq_lock);
>  
> @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
>  	 */
>  	if (s3c_freq->is_dvs) {
>  		pr_debug("cpufreq: leave dvs on reboot\n");
> -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> +
> +		memset(&policy, 0, sizeof(policy));
> +		ret = cpufreq_get_policy(&policy, 0);
> +		if (ret < 0) {
> +			pr_debug("cpufreq: get no policy for cpu0\n");
> +			return NOTIFY_BAD;
> +		}
> +

This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
put() instead ?

> +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
>  		if (ret < 0)
>  			return NOTIFY_BAD;
>  	}
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> index 5d10030..d99b4b1 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
>  						 unsigned long event, void *ptr)
>  {
>  	int ret;
> +	struct cpufreq_policy *policy;
>  
> -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> +	policy = cpufreq_cpu_get(0);
> +	if (!policy) {
> +		pr_debug("cpufreq: get no policy for cpu0\n");
> +		return NOTIFY_BAD;
> +	}
> +
> +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> +	cpufreq_cpu_put(policy);

Like what is done here.

Also add a blank line here.

>  	if (ret < 0)
>  		return NOTIFY_BAD;
>  
> -- 
> 1.9.1

-- 
viresh

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
@ 2020-01-06  5:48   ` Viresh Kumar
  0 siblings, 0 replies; 12+ messages in thread
From: Viresh Kumar @ 2020-01-06  5:48 UTC (permalink / raw)
  To: qiwuchen55
  Cc: linux-samsung-soc, linux-pm, rjw, linux-kernel, krzk, kgene,
	chenqiwu, linux-arm-kernel

On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> From: chenqiwu <chenqiwu@xiaomi.com>
> 
> There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> the cpufreq policy of cpu0 has been released before using it. So we should
> make a judgement to avoid it.

There is no UAF problem here, but that we do cpufreq_cpu_get() with a
corresponding cpufreq_cpu_put().

> Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> ---
>  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
>  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> index 1069103..0f576ba 100644
> --- a/drivers/cpufreq/s3c2416-cpufreq.c
> +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
>  {
>  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
>  	int ret;
> +	struct cpufreq_policy policy;
>  
>  	mutex_lock(&cpufreq_lock);
>  
> @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
>  	 */
>  	if (s3c_freq->is_dvs) {
>  		pr_debug("cpufreq: leave dvs on reboot\n");
> -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> +
> +		memset(&policy, 0, sizeof(policy));
> +		ret = cpufreq_get_policy(&policy, 0);
> +		if (ret < 0) {
> +			pr_debug("cpufreq: get no policy for cpu0\n");
> +			return NOTIFY_BAD;
> +		}
> +

This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
put() instead ?

> +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
>  		if (ret < 0)
>  			return NOTIFY_BAD;
>  	}
> diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> index 5d10030..d99b4b1 100644
> --- a/drivers/cpufreq/s5pv210-cpufreq.c
> +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
>  						 unsigned long event, void *ptr)
>  {
>  	int ret;
> +	struct cpufreq_policy *policy;
>  
> -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> +	policy = cpufreq_cpu_get(0);
> +	if (!policy) {
> +		pr_debug("cpufreq: get no policy for cpu0\n");
> +		return NOTIFY_BAD;
> +	}
> +
> +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> +	cpufreq_cpu_put(policy);

Like what is done here.

Also add a blank line here.

>  	if (ret < 0)
>  		return NOTIFY_BAD;
>  
> -- 
> 1.9.1

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
  2020-01-06  5:48   ` Viresh Kumar
@ 2020-01-06  6:52     ` chenqiwu
  -1 siblings, 0 replies; 12+ messages in thread
From: chenqiwu @ 2020-01-06  6:52 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: kgene, krzk, rjw, linux-arm-kernel, linux-samsung-soc, linux-pm

On Mon, Jan 06, 2020 at 11:18:11AM +0530, Viresh Kumar wrote:
> On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> > From: chenqiwu <chenqiwu@xiaomi.com>
> > 
> > There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> > the cpufreq policy of cpu0 has been released before using it. So we should
> > make a judgement to avoid it.
> 
> There is no UAF problem here, but that we do cpufreq_cpu_get() with a
> corresponding cpufreq_cpu_put().
> 
> > Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> > ---
> >  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
> >  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
> >  2 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> > index 1069103..0f576ba 100644
> > --- a/drivers/cpufreq/s3c2416-cpufreq.c
> > +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> > @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> >  {
> >  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
> >  	int ret;
> > +	struct cpufreq_policy policy;
> >  
> >  	mutex_lock(&cpufreq_lock);
> >  
> > @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> >  	 */
> >  	if (s3c_freq->is_dvs) {
> >  		pr_debug("cpufreq: leave dvs on reboot\n");
> > -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> > +
> > +		memset(&policy, 0, sizeof(policy));
> > +		ret = cpufreq_get_policy(&policy, 0);
> > +		if (ret < 0) {
> > +			pr_debug("cpufreq: get no policy for cpu0\n");
> > +			return NOTIFY_BAD;
> > +		}
> > +
> 
> This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
> put() instead ?
>
Hi viresh,
I can't explain which approach is better, but I think both approaches are
effective for the situation.
By the way, there is a possibility that the cpu0 hotplug thread will call
cpufreq_policy_free() to free cpufreq policy if cpu0 hotplug failed.
I think there should be a judgement to avoid this UAF risk if necessary,
or we just do panic if cpu0's cpufreq policy is free.

> > +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
> >  		if (ret < 0)
> >  			return NOTIFY_BAD;
> >  	}
> > diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> > index 5d10030..d99b4b1 100644
> > --- a/drivers/cpufreq/s5pv210-cpufreq.c
> > +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> > @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
> >  						 unsigned long event, void *ptr)
> >  {
> >  	int ret;
> > +	struct cpufreq_policy *policy;
> >  
> > -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> > +	policy = cpufreq_cpu_get(0);
> > +	if (!policy) {
> > +		pr_debug("cpufreq: get no policy for cpu0\n");
> > +		return NOTIFY_BAD;
> > +	}
> > +
> > +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> > +	cpufreq_cpu_put(policy);
> 
> Like what is done here.
> 
> Also add a blank line here.
> 
> >  	if (ret < 0)
> >  		return NOTIFY_BAD;
> >  
> > -- 
> > 1.9.1
> 
> -- 
> viresh

Thanks for your review!
Qiwu


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
@ 2020-01-06  6:52     ` chenqiwu
  0 siblings, 0 replies; 12+ messages in thread
From: chenqiwu @ 2020-01-06  6:52 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: linux-samsung-soc, linux-pm, rjw, krzk, kgene, linux-arm-kernel

On Mon, Jan 06, 2020 at 11:18:11AM +0530, Viresh Kumar wrote:
> On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> > From: chenqiwu <chenqiwu@xiaomi.com>
> > 
> > There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> > the cpufreq policy of cpu0 has been released before using it. So we should
> > make a judgement to avoid it.
> 
> There is no UAF problem here, but that we do cpufreq_cpu_get() with a
> corresponding cpufreq_cpu_put().
> 
> > Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> > ---
> >  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
> >  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
> >  2 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> > index 1069103..0f576ba 100644
> > --- a/drivers/cpufreq/s3c2416-cpufreq.c
> > +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> > @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> >  {
> >  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
> >  	int ret;
> > +	struct cpufreq_policy policy;
> >  
> >  	mutex_lock(&cpufreq_lock);
> >  
> > @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> >  	 */
> >  	if (s3c_freq->is_dvs) {
> >  		pr_debug("cpufreq: leave dvs on reboot\n");
> > -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> > +
> > +		memset(&policy, 0, sizeof(policy));
> > +		ret = cpufreq_get_policy(&policy, 0);
> > +		if (ret < 0) {
> > +			pr_debug("cpufreq: get no policy for cpu0\n");
> > +			return NOTIFY_BAD;
> > +		}
> > +
> 
> This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
> put() instead ?
>
Hi viresh,
I can't explain which approach is better, but I think both approaches are
effective for the situation.
By the way, there is a possibility that the cpu0 hotplug thread will call
cpufreq_policy_free() to free cpufreq policy if cpu0 hotplug failed.
I think there should be a judgement to avoid this UAF risk if necessary,
or we just do panic if cpu0's cpufreq policy is free.

> > +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
> >  		if (ret < 0)
> >  			return NOTIFY_BAD;
> >  	}
> > diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> > index 5d10030..d99b4b1 100644
> > --- a/drivers/cpufreq/s5pv210-cpufreq.c
> > +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> > @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
> >  						 unsigned long event, void *ptr)
> >  {
> >  	int ret;
> > +	struct cpufreq_policy *policy;
> >  
> > -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> > +	policy = cpufreq_cpu_get(0);
> > +	if (!policy) {
> > +		pr_debug("cpufreq: get no policy for cpu0\n");
> > +		return NOTIFY_BAD;
> > +	}
> > +
> > +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> > +	cpufreq_cpu_put(policy);
> 
> Like what is done here.
> 
> Also add a blank line here.
> 
> >  	if (ret < 0)
> >  		return NOTIFY_BAD;
> >  
> > -- 
> > 1.9.1
> 
> -- 
> viresh

Thanks for your review!
Qiwu


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
  2020-01-06  6:52     ` chenqiwu
@ 2020-01-06  6:55       ` Viresh Kumar
  -1 siblings, 0 replies; 12+ messages in thread
From: Viresh Kumar @ 2020-01-06  6:55 UTC (permalink / raw)
  To: chenqiwu; +Cc: kgene, krzk, rjw, linux-arm-kernel, linux-samsung-soc, linux-pm

On 06-01-20, 14:52, chenqiwu wrote:
> On Mon, Jan 06, 2020 at 11:18:11AM +0530, Viresh Kumar wrote:
> > On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> > > From: chenqiwu <chenqiwu@xiaomi.com>
> > > 
> > > There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> > > the cpufreq policy of cpu0 has been released before using it. So we should
> > > make a judgement to avoid it.
> > 
> > There is no UAF problem here, but that we do cpufreq_cpu_get() with a
> > corresponding cpufreq_cpu_put().
> > 
> > > Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> > > ---
> > >  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
> > >  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
> > >  2 files changed, 19 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> > > index 1069103..0f576ba 100644
> > > --- a/drivers/cpufreq/s3c2416-cpufreq.c
> > > +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> > > @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > >  {
> > >  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
> > >  	int ret;
> > > +	struct cpufreq_policy policy;
> > >  
> > >  	mutex_lock(&cpufreq_lock);
> > >  
> > > @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > >  	 */
> > >  	if (s3c_freq->is_dvs) {
> > >  		pr_debug("cpufreq: leave dvs on reboot\n");
> > > -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> > > +
> > > +		memset(&policy, 0, sizeof(policy));
> > > +		ret = cpufreq_get_policy(&policy, 0);
> > > +		if (ret < 0) {
> > > +			pr_debug("cpufreq: get no policy for cpu0\n");
> > > +			return NOTIFY_BAD;
> > > +		}
> > > +
> > 
> > This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
> > put() instead ?
> >
> Hi viresh,
> I can't explain which approach is better, but I think both approaches are
> effective for the situation.

The second one is better as it doesn't make copy of the policy, but
rather just increments the counter.

> By the way, there is a possibility that the cpu0 hotplug thread will call
> cpufreq_policy_free() to free cpufreq policy if cpu0 hotplug failed.
> I think there should be a judgement to avoid this UAF risk if necessary,
> or we just do panic if cpu0's cpufreq policy is free.

I think there are enough locks in place to avoid such issues and they
shouldn't happen.

> > > +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
> > >  		if (ret < 0)
> > >  			return NOTIFY_BAD;
> > >  	}
> > > diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> > > index 5d10030..d99b4b1 100644
> > > --- a/drivers/cpufreq/s5pv210-cpufreq.c
> > > +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> > > @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
> > >  						 unsigned long event, void *ptr)
> > >  {
> > >  	int ret;
> > > +	struct cpufreq_policy *policy;
> > >  
> > > -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> > > +	policy = cpufreq_cpu_get(0);
> > > +	if (!policy) {
> > > +		pr_debug("cpufreq: get no policy for cpu0\n");
> > > +		return NOTIFY_BAD;
> > > +	}
> > > +
> > > +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> > > +	cpufreq_cpu_put(policy);
> > 
> > Like what is done here.
> > 
> > Also add a blank line here.
> > 
> > >  	if (ret < 0)
> > >  		return NOTIFY_BAD;
> > >  
> > > -- 
> > > 1.9.1
> > 
> > -- 
> > viresh
> 
> Thanks for your review!
> Qiwu

-- 
viresh

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
@ 2020-01-06  6:55       ` Viresh Kumar
  0 siblings, 0 replies; 12+ messages in thread
From: Viresh Kumar @ 2020-01-06  6:55 UTC (permalink / raw)
  To: chenqiwu; +Cc: linux-samsung-soc, linux-pm, rjw, krzk, kgene, linux-arm-kernel

On 06-01-20, 14:52, chenqiwu wrote:
> On Mon, Jan 06, 2020 at 11:18:11AM +0530, Viresh Kumar wrote:
> > On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> > > From: chenqiwu <chenqiwu@xiaomi.com>
> > > 
> > > There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> > > the cpufreq policy of cpu0 has been released before using it. So we should
> > > make a judgement to avoid it.
> > 
> > There is no UAF problem here, but that we do cpufreq_cpu_get() with a
> > corresponding cpufreq_cpu_put().
> > 
> > > Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> > > ---
> > >  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
> > >  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
> > >  2 files changed, 19 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> > > index 1069103..0f576ba 100644
> > > --- a/drivers/cpufreq/s3c2416-cpufreq.c
> > > +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> > > @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > >  {
> > >  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
> > >  	int ret;
> > > +	struct cpufreq_policy policy;
> > >  
> > >  	mutex_lock(&cpufreq_lock);
> > >  
> > > @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > >  	 */
> > >  	if (s3c_freq->is_dvs) {
> > >  		pr_debug("cpufreq: leave dvs on reboot\n");
> > > -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> > > +
> > > +		memset(&policy, 0, sizeof(policy));
> > > +		ret = cpufreq_get_policy(&policy, 0);
> > > +		if (ret < 0) {
> > > +			pr_debug("cpufreq: get no policy for cpu0\n");
> > > +			return NOTIFY_BAD;
> > > +		}
> > > +
> > 
> > This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
> > put() instead ?
> >
> Hi viresh,
> I can't explain which approach is better, but I think both approaches are
> effective for the situation.

The second one is better as it doesn't make copy of the policy, but
rather just increments the counter.

> By the way, there is a possibility that the cpu0 hotplug thread will call
> cpufreq_policy_free() to free cpufreq policy if cpu0 hotplug failed.
> I think there should be a judgement to avoid this UAF risk if necessary,
> or we just do panic if cpu0's cpufreq policy is free.

I think there are enough locks in place to avoid such issues and they
shouldn't happen.

> > > +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
> > >  		if (ret < 0)
> > >  			return NOTIFY_BAD;
> > >  	}
> > > diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> > > index 5d10030..d99b4b1 100644
> > > --- a/drivers/cpufreq/s5pv210-cpufreq.c
> > > +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> > > @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
> > >  						 unsigned long event, void *ptr)
> > >  {
> > >  	int ret;
> > > +	struct cpufreq_policy *policy;
> > >  
> > > -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> > > +	policy = cpufreq_cpu_get(0);
> > > +	if (!policy) {
> > > +		pr_debug("cpufreq: get no policy for cpu0\n");
> > > +		return NOTIFY_BAD;
> > > +	}
> > > +
> > > +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> > > +	cpufreq_cpu_put(policy);
> > 
> > Like what is done here.
> > 
> > Also add a blank line here.
> > 
> > >  	if (ret < 0)
> > >  		return NOTIFY_BAD;
> > >  
> > > -- 
> > > 1.9.1
> > 
> > -- 
> > viresh
> 
> Thanks for your review!
> Qiwu

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
  2020-01-06  6:55       ` Viresh Kumar
@ 2020-01-06  8:30         ` chenqiwu
  -1 siblings, 0 replies; 12+ messages in thread
From: chenqiwu @ 2020-01-06  8:30 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: kgene, krzk, rjw, linux-arm-kernel, linux-samsung-soc, linux-pm

On Mon, Jan 06, 2020 at 12:25:02PM +0530, Viresh Kumar wrote:
> On 06-01-20, 14:52, chenqiwu wrote:
> > On Mon, Jan 06, 2020 at 11:18:11AM +0530, Viresh Kumar wrote:
> > > On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> > > > From: chenqiwu <chenqiwu@xiaomi.com>
> > > > 
> > > > There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> > > > the cpufreq policy of cpu0 has been released before using it. So we should
> > > > make a judgement to avoid it.
> > > 
> > > There is no UAF problem here, but that we do cpufreq_cpu_get() with a
> > > corresponding cpufreq_cpu_put().
> > > 
> > > > Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> > > > ---
> > > >  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
> > > >  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
> > > >  2 files changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> > > > index 1069103..0f576ba 100644
> > > > --- a/drivers/cpufreq/s3c2416-cpufreq.c
> > > > +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> > > > @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > > >  {
> > > >  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
> > > >  	int ret;
> > > > +	struct cpufreq_policy policy;
> > > >  
> > > >  	mutex_lock(&cpufreq_lock);
> > > >  
> > > > @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > > >  	 */
> > > >  	if (s3c_freq->is_dvs) {
> > > >  		pr_debug("cpufreq: leave dvs on reboot\n");
> > > > -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> > > > +
> > > > +		memset(&policy, 0, sizeof(policy));
> > > > +		ret = cpufreq_get_policy(&policy, 0);
> > > > +		if (ret < 0) {
> > > > +			pr_debug("cpufreq: get no policy for cpu0\n");
> > > > +			return NOTIFY_BAD;
> > > > +		}
> > > > +
> > > 
> > > This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
> > > put() instead ?
> > >
> > Hi viresh,
> > I can't explain which approach is better, but I think both approaches are
> > effective for the situation.
> 
> The second one is better as it doesn't make copy of the policy, but
> rather just increments the counter.
> 
> > By the way, there is a possibility that the cpu0 hotplug thread will call
> > cpufreq_policy_free() to free cpufreq policy if cpu0 hotplug failed.
> > I think there should be a judgement to avoid this UAF risk if necessary,
> > or we just do panic if cpu0's cpufreq policy is free.
> 
> I think there are enough locks in place to avoid such issues and they
> shouldn't happen.
>

Hhh..I don't agree this, since the cpufreq policy of cpu0 may have
been released before such UAF issue happenning.
By the way, why not get invaild cpufreq policy of another cpu but
only cpu0 here?

> > > > +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
> > > >  		if (ret < 0)
> > > >  			return NOTIFY_BAD;
> > > >  	}
> > > > diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> > > > index 5d10030..d99b4b1 100644
> > > > --- a/drivers/cpufreq/s5pv210-cpufreq.c
> > > > +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> > > > @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
> > > >  						 unsigned long event, void *ptr)
> > > >  {
> > > >  	int ret;
> > > > +	struct cpufreq_policy *policy;
> > > >  
> > > > -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> > > > +	policy = cpufreq_cpu_get(0);
> > > > +	if (!policy) {
> > > > +		pr_debug("cpufreq: get no policy for cpu0\n");
> > > > +		return NOTIFY_BAD;
> > > > +	}
> > > > +
> > > > +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> > > > +	cpufreq_cpu_put(policy);
> > > 
> > > Like what is done here.
> > > 
> > > Also add a blank line here.
> > > 
> > > >  	if (ret < 0)
> > > >  		return NOTIFY_BAD;
> > > >  
> > > > -- 
> > > > 1.9.1
> > > 
> > > -- 
> > > viresh
> > 
> > Thanks for your review!
> > Qiwu
> 
> -- 
> viresh

Thanks!
Qiwu

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
@ 2020-01-06  8:30         ` chenqiwu
  0 siblings, 0 replies; 12+ messages in thread
From: chenqiwu @ 2020-01-06  8:30 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: linux-samsung-soc, linux-pm, rjw, krzk, kgene, linux-arm-kernel

On Mon, Jan 06, 2020 at 12:25:02PM +0530, Viresh Kumar wrote:
> On 06-01-20, 14:52, chenqiwu wrote:
> > On Mon, Jan 06, 2020 at 11:18:11AM +0530, Viresh Kumar wrote:
> > > On 28-12-19, 14:43, qiwuchen55@gmail.com wrote:
> > > > From: chenqiwu <chenqiwu@xiaomi.com>
> > > > 
> > > > There is a potential UAF issue in xxx_cpufreq_reboot_notifier_evt() that
> > > > the cpufreq policy of cpu0 has been released before using it. So we should
> > > > make a judgement to avoid it.
> > > 
> > > There is no UAF problem here, but that we do cpufreq_cpu_get() with a
> > > corresponding cpufreq_cpu_put().
> > > 
> > > > Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> > > > ---
> > > >  drivers/cpufreq/s3c2416-cpufreq.c | 11 ++++++++++-
> > > >  drivers/cpufreq/s5pv210-cpufreq.c | 10 +++++++++-
> > > >  2 files changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> > > > index 1069103..0f576ba 100644
> > > > --- a/drivers/cpufreq/s3c2416-cpufreq.c
> > > > +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> > > > @@ -304,6 +304,7 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > > >  {
> > > >  	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
> > > >  	int ret;
> > > > +	struct cpufreq_policy policy;
> > > >  
> > > >  	mutex_lock(&cpufreq_lock);
> > > >  
> > > > @@ -318,7 +319,15 @@ static int s3c2416_cpufreq_reboot_notifier_evt(struct notifier_block *this,
> > > >  	 */
> > > >  	if (s3c_freq->is_dvs) {
> > > >  		pr_debug("cpufreq: leave dvs on reboot\n");
> > > > -		ret = cpufreq_driver_target(cpufreq_cpu_get(0), FREQ_SLEEP, 0);
> > > > +
> > > > +		memset(&policy, 0, sizeof(policy));
> > > > +		ret = cpufreq_get_policy(&policy, 0);
> > > > +		if (ret < 0) {
> > > > +			pr_debug("cpufreq: get no policy for cpu0\n");
> > > > +			return NOTIFY_BAD;
> > > > +		}
> > > > +
> > > 
> > > This doesn't make sense to me, why don't you do cpufreq_cpu_get() and
> > > put() instead ?
> > >
> > Hi viresh,
> > I can't explain which approach is better, but I think both approaches are
> > effective for the situation.
> 
> The second one is better as it doesn't make copy of the policy, but
> rather just increments the counter.
> 
> > By the way, there is a possibility that the cpu0 hotplug thread will call
> > cpufreq_policy_free() to free cpufreq policy if cpu0 hotplug failed.
> > I think there should be a judgement to avoid this UAF risk if necessary,
> > or we just do panic if cpu0's cpufreq policy is free.
> 
> I think there are enough locks in place to avoid such issues and they
> shouldn't happen.
>

Hhh..I don't agree this, since the cpufreq policy of cpu0 may have
been released before such UAF issue happenning.
By the way, why not get invaild cpufreq policy of another cpu but
only cpu0 here?

> > > > +		ret = cpufreq_driver_target(&policy, FREQ_SLEEP, 0);
> > > >  		if (ret < 0)
> > > >  			return NOTIFY_BAD;
> > > >  	}
> > > > diff --git a/drivers/cpufreq/s5pv210-cpufreq.c b/drivers/cpufreq/s5pv210-cpufreq.c
> > > > index 5d10030..d99b4b1 100644
> > > > --- a/drivers/cpufreq/s5pv210-cpufreq.c
> > > > +++ b/drivers/cpufreq/s5pv210-cpufreq.c
> > > > @@ -555,8 +555,16 @@ static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
> > > >  						 unsigned long event, void *ptr)
> > > >  {
> > > >  	int ret;
> > > > +	struct cpufreq_policy *policy;
> > > >  
> > > > -	ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
> > > > +	policy = cpufreq_cpu_get(0);
> > > > +	if (!policy) {
> > > > +		pr_debug("cpufreq: get no policy for cpu0\n");
> > > > +		return NOTIFY_BAD;
> > > > +	}
> > > > +
> > > > +	ret = cpufreq_driver_target(policy, SLEEP_FREQ, 0);
> > > > +	cpufreq_cpu_put(policy);
> > > 
> > > Like what is done here.
> > > 
> > > Also add a blank line here.
> > > 
> > > >  	if (ret < 0)
> > > >  		return NOTIFY_BAD;
> > > >  
> > > > -- 
> > > > 1.9.1
> > > 
> > > -- 
> > > viresh
> > 
> > Thanks for your review!
> > Qiwu
> 
> -- 
> viresh

Thanks!
Qiwu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
  2020-01-06  8:30         ` chenqiwu
@ 2020-01-07  5:29           ` Viresh Kumar
  -1 siblings, 0 replies; 12+ messages in thread
From: Viresh Kumar @ 2020-01-07  5:29 UTC (permalink / raw)
  To: chenqiwu; +Cc: kgene, krzk, rjw, linux-arm-kernel, linux-samsung-soc, linux-pm

On 06-01-20, 16:30, chenqiwu wrote:
> Hhh..I don't agree this, since the cpufreq policy of cpu0 may have
> been released before such UAF issue happenning.

That won't happen if you do cpufreq_cpu_get(), isn't it ?

> By the way, why not get invaild cpufreq policy of another cpu but
> only cpu0 here?

Probably because this platform has a single cpufreq policy which covers all the
CPUs and so it doesn't really matter which CPU you use to get the policy.

-- 
viresh

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt()
@ 2020-01-07  5:29           ` Viresh Kumar
  0 siblings, 0 replies; 12+ messages in thread
From: Viresh Kumar @ 2020-01-07  5:29 UTC (permalink / raw)
  To: chenqiwu; +Cc: linux-samsung-soc, linux-pm, rjw, krzk, kgene, linux-arm-kernel

On 06-01-20, 16:30, chenqiwu wrote:
> Hhh..I don't agree this, since the cpufreq policy of cpu0 may have
> been released before such UAF issue happenning.

That won't happen if you do cpufreq_cpu_get(), isn't it ?

> By the way, why not get invaild cpufreq policy of another cpu but
> only cpu0 here?

Probably because this platform has a single cpufreq policy which covers all the
CPUs and so it doesn't really matter which CPU you use to get the policy.

-- 
viresh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2020-01-07  5:29 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-28  6:43 [PATCH] cpufreq: s3c: avoid use after free issue in xxx_cpufreq_reboot_notifier_evt() qiwuchen55
2019-12-28  6:43 ` qiwuchen55
2020-01-06  5:48 ` Viresh Kumar
2020-01-06  5:48   ` Viresh Kumar
2020-01-06  6:52   ` chenqiwu
2020-01-06  6:52     ` chenqiwu
2020-01-06  6:55     ` Viresh Kumar
2020-01-06  6:55       ` Viresh Kumar
2020-01-06  8:30       ` chenqiwu
2020-01-06  8:30         ` chenqiwu
2020-01-07  5:29         ` Viresh Kumar
2020-01-07  5:29           ` Viresh Kumar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.