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
next 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.