diff mbox series

workqueue: Add a new flag to spot the potential UAF error

Message ID 20221213043936.6345-1-richard.xnu.clark@gmail.com
State New
Headers
Series workqueue: Add a new flag to spot the potential UAF error |

Commit Message

richard clark Dec. 13, 2022, 4:39 a.m. UTC 
  Currently if the user queues a new work item unintentionally
into a wq after the destroy_workqueue(wq), the work still can
be queued and scheduled without any noticeable kernel message
before the end of a RCU grace period.

As a debug-aid facility, this commit adds a new flag
__WQ_DESTROYING to spot that issue by triggering a kernel WARN
message.

Signed-off-by: Richard Clark <richard.xnu.clark@gmail.com>
---
 include/linux/workqueue.h |  1 +
 kernel/workqueue.c        | 15 ++++++++++++---
 2 files changed, 13 insertions(+), 3 deletions(-)

Comments

Lai Jiangshan Dec. 14, 2022, 7:16 a.m. UTC | #1 
On Tue, Dec 13, 2022 at 12:40 PM Richard Clark
<richard.xnu.clark@gmail.com> wrote:
>
> Currently if the user queues a new work item unintentionally
> into a wq after the destroy_workqueue(wq), the work still can
> be queued and scheduled without any noticeable kernel message
> before the end of a RCU grace period.
>
> As a debug-aid facility, this commit adds a new flag
> __WQ_DESTROYING to spot that issue by triggering a kernel WARN
> message.
>
> Signed-off-by: Richard Clark <richard.xnu.clark@gmail.com>

Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>
richard clark Dec. 16, 2022, 1:14 a.m. UTC | #2 
Hello TJ,

On Wed, Dec 14, 2022 at 3:16 PM Lai Jiangshan <jiangshanlai@gmail.com> wrote:
>
> On Tue, Dec 13, 2022 at 12:40 PM Richard Clark
> <richard.xnu.clark@gmail.com> wrote:
> >
> > Currently if the user queues a new work item unintentionally
> > into a wq after the destroy_workqueue(wq), the work still can
> > be queued and scheduled without any noticeable kernel message
> > before the end of a RCU grace period.
> >
> > As a debug-aid facility, this commit adds a new flag
> > __WQ_DESTROYING to spot that issue by triggering a kernel WARN
> > message.
> >
> > Signed-off-by: Richard Clark <richard.xnu.clark@gmail.com>
>
> Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>

What do I need to do for this patch next?

Thanks
Tejun Heo Jan. 4, 2023, 10:26 p.m. UTC | #3 
On Tue, Dec 13, 2022 at 12:39:36PM +0800, Richard Clark wrote:
> Currently if the user queues a new work item unintentionally
> into a wq after the destroy_workqueue(wq), the work still can
> be queued and scheduled without any noticeable kernel message
> before the end of a RCU grace period.
> 
> As a debug-aid facility, this commit adds a new flag
> __WQ_DESTROYING to spot that issue by triggering a kernel WARN
> message.
> 
> Signed-off-by: Richard Clark <richard.xnu.clark@gmail.com>

Applied to wq/for-6.3 w/ whitespace adjustments.

Thanks.
diff mbox series

Patch

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index a0143dd24430..ac551b8ee7d9 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -335,6 +335,7 @@  enum {
 	 */
 	WQ_POWER_EFFICIENT	= 1 << 7,
 
+	__WQ_DESTROYING		= 1 << 15, /* internal: workqueue is destroying */
 	__WQ_DRAINING		= 1 << 16, /* internal: workqueue is draining */
 	__WQ_ORDERED		= 1 << 17, /* internal: workqueue is ordered */
 	__WQ_LEGACY		= 1 << 18, /* internal: create*_workqueue() */
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 39060a5d0905..30dc6869b3fd 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1433,9 +1433,13 @@  static void __queue_work(int cpu, struct workqueue_struct *wq,
 	lockdep_assert_irqs_disabled();
 
 
-	/* if draining, only works from the same workqueue are allowed */
-	if (unlikely(wq->flags & __WQ_DRAINING) &&
-	    WARN_ON_ONCE(!is_chained_work(wq)))
+	/*
+	 * For a draining wq, only works from the same workqueue are
+	 * allowed. The __WQ_DESTROYING helps to spot the issue that
+	 * queues a new work item to a wq after destroy_workqueue(wq).
+	 */
+	if (unlikely(wq->flags & (__WQ_DESTROYING | __WQ_DRAINING)
+		&& WARN_ON_ONCE(!is_chained_work(wq))))
 		return;
 	rcu_read_lock();
 retry:
@@ -4414,6 +4418,11 @@  void destroy_workqueue(struct workqueue_struct *wq)
 	 */
 	workqueue_sysfs_unregister(wq);
 
+	/* mark the workqueue destruction is in progress */
+	mutex_lock(&wq->mutex);
+	wq->flags |= __WQ_DESTROYING;
+	mutex_unlock(&wq->mutex);
+
 	/* drain it before proceeding with destruction */
 	drain_workqueue(wq);