rfkill: fix rfkill_fop_read wait_event usage (6736fde9) · Commits · 戴 / test

The code within wait_event_interruptible() is called with !TASK_RUNNING, so mustn't call any functions that can sleep, like mutex_lock(). Since we re-check the list_empty() in a loop after the wait, it's safe to simply use list_empty() without locking. This bug has existed forever, but was only discovered now because all userspace implementations, including the default 'rfkill' tool, use poll() or select() to get a readable fd before attempting to read. Cc: stable@vger.kernel.org Fixes: ("rfkill: create useful userspace interface") Reported-by:

Dmitry Vyukov <dvyukov@google.com> Signed-off-by:

Johannes Berg <johannes.berg@intel.com>

net/rfkill/core.c

+4 −12

Original line number	Diff line number	Diff line
		@@ -1095,17 +1095,6 @@ static unsigned int rfkill_fop_poll(struct file file, poll_table wait)
		return res;
		}

		static bool rfkill_readable(struct rfkill_data *data)
		{
		bool r;

		mutex_lock(&data->mtx);
		r = !list_empty(&data->events);
		mutex_unlock(&data->mtx);

		return r;
		}

		static ssize_t rfkill_fop_read(struct file file, char __user buf,
		size_t count, loff_t *pos)
		{
		@@ -1122,8 +1111,11 @@ static ssize_t rfkill_fop_read(struct file file, char __user buf,
		goto out;
		}
		mutex_unlock(&data->mtx);
		/* since we re-check and it just compares pointers,
		* using !list_empty() without locking isn't a problem
		*/
		ret = wait_event_interruptible(data->read_wait,
		rfkill_readable(data));
		!list_empty(&data->events));
		mutex_lock(&data->mtx);

		if (ret)

Admin message