linux-kernel - [PATCH v1 2/2] rtc: fix race condition in rtc_set

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

Message-ID: <20221109064147.1836133-3-liaoyu15@huawei.com>
Date:   Wed, 9 Nov 2022 14:41:47 +0800
From:   Yu Liao <liaoyu15@...wei.com>
To:     <alexandre.belloni@...tlin.com>, <a.zummo@...ertech.it>
CC:     <liaoyu15@...wei.com>, <liwei391@...wei.com>,
        <linux-kernel@...r.kernel.org>, <linux-rtc@...r.kernel.org>
Subject: [PATCH v1 2/2] rtc: fix race condition in rtc_set_time()

Commit 7e7c005b4b1f ("rtc: disable uie before setting time and enable
after") was introduced to solve problem that rtc_timer_do_work will loop
for a while, when setting the time in the future with the uie timer
enabled. But reading uie timer state and setting rtc time are not in
a critical section, a race condition may occur in rtc_set_time which
has two issues:

1) In the above scenario, rtc_timer_do_work may still loop for a while.
   For example consider the following sequence:

   CPU0					CPU1
   ----					----
   ioctl(RTC_SET_TIME)			ioctl(RTC_UIE_ON)
   uie = rtc->uie_rtctimer.enabled;
   [ assume uie is 0 ]
   if (uie)
   	rtc_update_irq_enable(rtc, 0);

   					rtc_update_irq_enable(rtc, 1);
   					[ uie is enabled ]
   rtc->ops->set_time();
   [ set rtc time in the future ]

2) A thread try to turn off uie, however rtc_settime called by another
   thread turns on uie when they run in parallel. Consider the following
   sequence:

   CPU0					CPU1
   ----					----
   ioctl(RTC_SET_TIME)			ioctl(RTC_UIE_OFF)
   rtc->ops->set_time();
   					rtc_update_irq_enable(rtc, 0);
   rtc_update_irq_enable(rtc, 1);

Fix it by guaranteeing that reading uie timer state, setting rtc time
and enabling uie timer within a critical section.

Fixes: 7e7c005b4b1f ("rtc: disable uie before setting time and enable after")
Signed-off-by: Yu Liao <liaoyu15@...wei.com>
---
 drivers/rtc/interface.c | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index bc55dd31bece..ef78e2977330 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -139,21 +139,23 @@ int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm)
 
 	rtc_subtract_offset(rtc, tm);
 
+	err = mutex_lock_interruptible(&rtc->ops_lock);
+	if (err)
+		return err;
+
 #ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL
 	uie = rtc->uie_rtctimer.enabled || rtc->uie_irq_active;
 #else
 	uie = rtc->uie_rtctimer.enabled;
 #endif
 	if (uie) {
-		err = rtc_update_irq_enable(rtc, 0);
-		if (err)
+		err = __rtc_update_irq_enable(rtc, 0);
+		if (err) {
+			mutex_unlock(&rtc->ops_lock);
 			return err;
+		}
 	}
 
-	err = mutex_lock_interruptible(&rtc->ops_lock);
-	if (err)
-		return err;
-
 	if (!rtc->ops)
 		err = -ENODEV;
 	else if (rtc->ops->set_time)
@@ -162,15 +164,17 @@ int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm)
 		err = -EINVAL;
 
 	pm_stay_awake(rtc->dev.parent);
-	mutex_unlock(&rtc->ops_lock);
 	/* A timer might have just expired */
 	schedule_work(&rtc->irqwork);
 
 	if (uie) {
-		err = rtc_update_irq_enable(rtc, 1);
-		if (err)
+		err = __rtc_update_irq_enable(rtc, 1);
+		if (err) {
+			mutex_unlock(&rtc->ops_lock);
 			return err;
+		}
 	}
+	mutex_unlock(&rtc->ops_lock);
 
 	trace_rtc_set_time(rtc_tm_to_time64(tm), err);
 	return err;
-- 
2.25.1