linux-kernel - [PATCH v2] PM / devfreq: Fix atomicity violation in devfreq_update

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>] [day] [month] [year] [list]

Message-Id: <20241030064928.6180-1-chenqiuji666@gmail.com>
Date: Wed, 30 Oct 2024 14:49:28 +0800
From: Qiu-ji Chen <chenqiuji666@...il.com>
To: myungjoo.ham@...sung.com,
	kyungmin.park@...sung.com,
	cw00.choi@...sung.com
Cc: linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	baijiaju1990@...il.com,
	Qiu-ji Chen <chenqiuji666@...il.com>,
	stable@...r.kernel.org
Subject: [PATCH v2] PM / devfreq: Fix atomicity violation in devfreq_update_interval()

The atomicity violation occurs when the variables cur_delay and new_delay 
are defined. Imagine a scenario where, while defining cur_delay and 
new_delay, the values stored in devfreq->profile->polling_ms and the delay 
variable change. After acquiring the mutex_lock and entering the critical 
section, due to possible concurrent modifications, cur_delay and new_delay 
may no longer represent the correct values. Subsequent usage, such as if 
(cur_delay > new_delay), could cause the program to run incorrectly, 
resulting in inconsistencies.

If the read of devfreq->profile->polling_ms is not protected by the
lock, the cur_delay that enters the critical section would not store
the actual old value of devfreq->profile->polling_ms, which would
affect the subsequent checks like if (!cur_delay) and if (cur_delay >
new_delay), potentially causing the driver to perform incorrect
operations.

We believe that moving the read of devfreq->profile->polling_ms inside
the lock is beneficial as it ensures that cur_delay stores the true
old value of devfreq->profile->polling_ms, ensuring the correctness of
the later checks.

To address this issue, it is recommended to acquire a lock in advance, 
ensuring that devfreq->profile->polling_ms and delay are protected by the 
lock when being read. This will help ensure the consistency of the program.

This possible bug is found by an experimental static analysis tool
developed by our team. This tool analyzes the locking APIs
to extract function pairs that can be concurrently executed, and then
analyzes the instructions in the paired functions to identify possible
concurrency bugs including data races and atomicity violations.

Fixes: 7e6fdd4bad03 ("PM / devfreq: Core updates to support devices which can idle")
Cc: stable@...r.kernel.org
Signed-off-by: Qiu-ji Chen <chenqiuji666@...il.com>
---
V2: 
Added some descriptions to reduce misunderstandings.
Thanks to MyungJoo Ham for suggesting this improvement.
---
 drivers/devfreq/devfreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 98657d3b9435..9634739fc9cb 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -616,10 +616,10 @@ EXPORT_SYMBOL(devfreq_monitor_resume);
  */
 void devfreq_update_interval(struct devfreq *devfreq, unsigned int *delay)
 {
+	mutex_lock(&devfreq->lock);
 	unsigned int cur_delay = devfreq->profile->polling_ms;
 	unsigned int new_delay = *delay;

-	mutex_lock(&devfreq->lock);
 	devfreq->profile->polling_ms = new_delay;

 	if (IS_SUPPORTED_FLAG(devfreq->governor->flags, IRQ_DRIVEN))
-- 
2.34.1