All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tuo Li <islituo@gmail.com>
To: dtwlin@gmail.com, johan@kernel.org, elder@kernel.org,
	gregkh@linuxfoundation.org
Cc: greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org, baijiaju1990@outlook.com,
	Tuo Li <islituo@gmail.com>, BassCheck <bass@buaa.edu.cn>
Subject: [PATCH] staging: greybus: fix a possible data-inconsistency due to data race in get_serial_info()
Date: Mon, 26 Jun 2023 16:43:39 +0800	[thread overview]
Message-ID: <20230626084339.998784-1-islituo@gmail.com> (raw)

The variables gb_tty->port.close_delay and gb_tty->port.closing_wait are
ofter accessed together while holding the lock gb_tty->port.mutex. Here is 
an example in set_serial_info():

  mutex_lock(&gb_tty->port.mutex);
  ...
  gb_tty->port.close_delay = close_delay;
  gb_tty->port.closing_wait = closing_wait;
  ...
  mutex_unlock(&gb_tty->port.mutex);

However, they are accessed without holding the lock gb_tty->port.mutex when
are accessed in get_serial_info():

  ss->close_delay = jiffies_to_msecs(gb_tty->port.close_delay) / 10;
  ss->closing_wait =
    gb_tty->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ?
	ASYNC_CLOSING_WAIT_NONE :
	jiffies_to_msecs(gb_tty->port.closing_wait) / 10;

In my opinion, this may be a harmful race, because ss->close_delay can be
inconsistent with ss->closing_wait if gb_tty->port.close_delay and 
gb_tty->port.closing_wait are updated by another thread after the 
assignment to ss->close_delay.
Besides, the select operator may return wrong value if 
gb_tty->port.closing_wait is updated right after the condition is 
calculated.

To fix this possible data-inconsistency caused by data race, a lock and 
unlock pair is added when accessing different fields of gb_tty->port.

Reported-by: BassCheck <bass@buaa.edu.cn>
Signed-off-by: Tuo Li <islituo@gmail.com>
---
 drivers/staging/greybus/uart.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 20a34599859f..b8875517ea6a 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -596,12 +596,14 @@ static int get_serial_info(struct tty_struct *tty,
 {
 	struct gb_tty *gb_tty = tty->driver_data;
 
+	mutex_lock(&gb_tty->port.mutex);
 	ss->line = gb_tty->minor;
 	ss->close_delay = jiffies_to_msecs(gb_tty->port.close_delay) / 10;
 	ss->closing_wait =
 		gb_tty->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ?
 		ASYNC_CLOSING_WAIT_NONE :
 		jiffies_to_msecs(gb_tty->port.closing_wait) / 10;
+	mutex_unlock(&gb_tty->port.mutex);
 
 	return 0;
 }
-- 
2.34.1


             reply	other threads:[~2023-06-26  8:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26  8:43 Tuo Li [this message]
2023-07-03 13:23 ` [PATCH] staging: greybus: fix a possible data-inconsistency due to data race in get_serial_info() Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230626084339.998784-1-islituo@gmail.com \
    --to=islituo@gmail.com \
    --cc=baijiaju1990@outlook.com \
    --cc=bass@buaa.edu.cn \
    --cc=dtwlin@gmail.com \
    --cc=elder@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.