Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-06 02:48, Greg KH wrote:
On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
Potentially, hvc_open() can be called in parallel when two tasks calls
open() on /dev/hvcX. In such a scenario, if the
hp->ops->notifier_add()
callback in the function fails, where it sets the tty->driver_data to
NULL, the parallel hvc_open() can see this NULL and cause a memory
abort.
Hence, serialize hvc_open and check if tty->private_data is NULL
before
proceeding ahead.
The issue can be easily reproduced by launching two tasks
simultaneously
that does nothing but open() and close() on /dev/hvcX.
For example:
$ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
Signed-off-by: Raghavendra Rao Ananta
---
drivers/tty/hvc/hvc_console.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c
b/drivers/tty/hvc/hvc_console.c
index 436cc51c92c3..ebe26fe5ac09 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
*/
static DEFINE_MUTEX(hvc_structs_mutex);
+/* Mutex to serialize hvc_open */
+static DEFINE_MUTEX(hvc_open_mutex);
/*
* This value is used to assign a tty->index value to a hvc_struct
based
* upon order of exposure via hvc_probe(), when we can not match it
to
@@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
*driver, struct tty_struct *tty)
*/
static int hvc_open(struct tty_struct *tty, struct file * filp)
{
- struct hvc_struct *hp = tty->driver_data;
+ struct hvc_struct *hp;
unsigned long flags;
int rc = 0;
+ mutex_lock(&hvc_open_mutex);
+
+ hp = tty->driver_data;
+ if (!hp) {
+ rc = -EIO;
+ goto out;
+ }
+
spin_lock_irqsave(&hp->port.lock, flags);
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
hvc_kick();
- return 0;
+ goto out;
} /* else count == 0 */
spin_unlock_irqrestore(&hp->port.lock, flags);
Wait, why isn't this driver just calling tty_port_open() instead of
trying to open-code all of this?
Keeping a single mutext for open will not protect it from close, it
will
just slow things down a bit. There should already be a tty lock held
by
the tty core for open() to keep it from racing things, right?
The tty lock should have been held, but not likely across ->install()
and
->open() callbacks, thus resulting in a race between hvc_install() and
hvc_open(),
where hvc_install() sets a data and the hvc_open() clears it. hvc_open()
doesn't
check if the data was set to NULL and proceeds.
Try just removing all of this logic and replacing it with a call to
tty_port_open() and see if that fixes this issue.
As "proof" of this, I don't see other serial drivers needing a single
mutex for their open calls, do you?
thanks,
greg k-h
Thank you.
Raghavendra
Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-09 23:48, Greg KH wrote:
On Sat, May 09, 2020 at 06:30:56PM -0700, rana...@codeaurora.org wrote:
On 2020-05-06 02:48, Greg KH wrote:
> On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
> > Potentially, hvc_open() can be called in parallel when two tasks calls
> > open() on /dev/hvcX. In such a scenario, if the
> > hp->ops->notifier_add()
> > callback in the function fails, where it sets the tty->driver_data to
> > NULL, the parallel hvc_open() can see this NULL and cause a memory
> > abort.
> > Hence, serialize hvc_open and check if tty->private_data is NULL
> > before
> > proceeding ahead.
> >
> > The issue can be easily reproduced by launching two tasks
> > simultaneously
> > that does nothing but open() and close() on /dev/hvcX.
> > For example:
> > $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
> >
> > Signed-off-by: Raghavendra Rao Ananta
> > ---
> > drivers/tty/hvc/hvc_console.c | 16 ++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/hvc/hvc_console.c
> > b/drivers/tty/hvc/hvc_console.c
> > index 436cc51c92c3..ebe26fe5ac09 100644
> > --- a/drivers/tty/hvc/hvc_console.c
> > +++ b/drivers/tty/hvc/hvc_console.c
> > @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
> > */
> > static DEFINE_MUTEX(hvc_structs_mutex);
> >
> > +/* Mutex to serialize hvc_open */
> > +static DEFINE_MUTEX(hvc_open_mutex);
> > /*
> > * This value is used to assign a tty->index value to a hvc_struct
> > based
> > * upon order of exposure via hvc_probe(), when we can not match it
> > to
> > @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
> > *driver, struct tty_struct *tty)
> > */
> > static int hvc_open(struct tty_struct *tty, struct file * filp)
> > {
> > - struct hvc_struct *hp = tty->driver_data;
> > + struct hvc_struct *hp;
> > unsigned long flags;
> > int rc = 0;
> >
> > + mutex_lock(&hvc_open_mutex);
> > +
> > + hp = tty->driver_data;
> > + if (!hp) {
> > + rc = -EIO;
> > + goto out;
> > + }
> > +
> > spin_lock_irqsave(&hp->port.lock, flags);
> > /* Check and then increment for fast path open. */
> > if (hp->port.count++ > 0) {
> > spin_unlock_irqrestore(&hp->port.lock, flags);
> > hvc_kick();
> > - return 0;
> > + goto out;
> > } /* else count == 0 */
> > spin_unlock_irqrestore(&hp->port.lock, flags);
>
> Wait, why isn't this driver just calling tty_port_open() instead of
> trying to open-code all of this?
>
> Keeping a single mutext for open will not protect it from close, it will
> just slow things down a bit. There should already be a tty lock held by
> the tty core for open() to keep it from racing things, right?
The tty lock should have been held, but not likely across ->install()
and
->open() callbacks, thus resulting in a race between hvc_install() and
hvc_open(),
How? The tty lock is held in install, and should not conflict with
open(), otherwise, we would be seeing this happen in all tty drivers,
right?
Well, I was expecting the same, but IIRC, I see that the open() was
being
called in parallel for the same device node.
Is it expected that the tty core would allow only one thread to
access the dev-node, while blocking the other, or is it the client
driver's responsibility to handle the exclusiveness?
where hvc_install() sets a data and the hvc_open() clears it.
hvc_open()
doesn't
check if the data was set to NULL and proceeds.
What data is being set that hvc_open is checking?
hvc_install sets tty->private_data to hp, while hvc_open sets it to NULL
(in one of the paths).
And you are not grabbing a lock in your install callback, you are only
serializing your open call here, I don't see how this is fixing
anything
other than perhaps slowing down your codepaths.
Basically, my intention was to add a NULL check before accessing *hp in
open().
The intention of the lock was to protect against this check.
If the tty layer would have taken care of this, then perhaps there won't
be a
need to check for NULL.
As an arument why this isn't correct, can you answer why this same type
of change wouldn't be required for all tty drivers in the tree?
I agree, that if it's already taken care by the tty-core, we don't need
it here.
Correct me if I'm wrong, but looks like the tty layer is allowing
parallel accesses
to open(),
thanks,
greg k-h
Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-11 00:23, rana...@codeaurora.org wrote:
On 2020-05-09 23:48, Greg KH wrote:
On Sat, May 09, 2020 at 06:30:56PM -0700, rana...@codeaurora.org
wrote:
On 2020-05-06 02:48, Greg KH wrote:
> On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
> > Potentially, hvc_open() can be called in parallel when two tasks calls
> > open() on /dev/hvcX. In such a scenario, if the
> > hp->ops->notifier_add()
> > callback in the function fails, where it sets the tty->driver_data to
> > NULL, the parallel hvc_open() can see this NULL and cause a memory
> > abort.
> > Hence, serialize hvc_open and check if tty->private_data is NULL
> > before
> > proceeding ahead.
> >
> > The issue can be easily reproduced by launching two tasks
> > simultaneously
> > that does nothing but open() and close() on /dev/hvcX.
> > For example:
> > $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
> >
> > Signed-off-by: Raghavendra Rao Ananta
> > ---
> > drivers/tty/hvc/hvc_console.c | 16 ++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/hvc/hvc_console.c
> > b/drivers/tty/hvc/hvc_console.c
> > index 436cc51c92c3..ebe26fe5ac09 100644
> > --- a/drivers/tty/hvc/hvc_console.c
> > +++ b/drivers/tty/hvc/hvc_console.c
> > @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
> > */
> > static DEFINE_MUTEX(hvc_structs_mutex);
> >
> > +/* Mutex to serialize hvc_open */
> > +static DEFINE_MUTEX(hvc_open_mutex);
> > /*
> > * This value is used to assign a tty->index value to a hvc_struct
> > based
> > * upon order of exposure via hvc_probe(), when we can not match it
> > to
> > @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
> > *driver, struct tty_struct *tty)
> > */
> > static int hvc_open(struct tty_struct *tty, struct file * filp)
> > {
> > - struct hvc_struct *hp = tty->driver_data;
> > + struct hvc_struct *hp;
> > unsigned long flags;
> > int rc = 0;
> >
> > + mutex_lock(&hvc_open_mutex);
> > +
> > + hp = tty->driver_data;
> > + if (!hp) {
> > + rc = -EIO;
> > + goto out;
> > + }
> > +
> > spin_lock_irqsave(&hp->port.lock, flags);
> > /* Check and then increment for fast path open. */
> > if (hp->port.count++ > 0) {
> > spin_unlock_irqrestore(&hp->port.lock, flags);
> > hvc_kick();
> > - return 0;
> > + goto out;
> > } /* else count == 0 */
> > spin_unlock_irqrestore(&hp->port.lock, flags);
>
> Wait, why isn't this driver just calling tty_port_open() instead of
> trying to open-code all of this?
>
> Keeping a single mutext for open will not protect it from close, it will
> just slow things down a bit. There should already be a tty lock held by
> the tty core for open() to keep it from racing things, right?
The tty lock should have been held, but not likely across ->install()
and
->open() callbacks, thus resulting in a race between hvc_install()
and
hvc_open(),
How? The tty lock is held in install, and should not conflict with
open(), otherwise, we would be seeing this happen in all tty drivers,
right?
Well, I was expecting the same, but IIRC, I see that the open() was
being
called in parallel for the same device node.
Is it expected that the tty core would allow only one thread to
access the dev-node, while blocking the other, or is it the client
driver's responsibility to handle the exclusiveness?
Or is there any optimization going on where the second call doesn't go
through
install(), but calls open() directly as the file was already opened by
the first
thread?
where hvc_install() sets a data and the hvc_open() clears it.
hvc_open()
doesn't
check if the data was set to NULL and proceeds.
What data is being set that hvc_open is checking?
hvc_install sets tty->private_data to hp, while hvc_open sets it to
NULL (in one of the paths).
And you are not grabbing a lock in your install callback, you are only
serializing your open call here, I don't see how this is fixing
anything
other than perhaps slowing down your codepaths.
Basically, my intention was to add a NULL check before accessing *hp in
open().
The intention of the lock was to protect against this check.
If the tty layer would have taken care of this, then perhaps there
won't be a
need to check for NULL.
As an arument why this isn't correct, can you answer why this same
type
of change wouldn't be required for all tty drivers in the tree?
I agree, that if it's already taken care by the tty-core, we don't need
it here.
Correct me if I'm wrong, but looks like the tty layer is allowing
parallel accesses
to open(),
thanks,
greg k-h
Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-12 01:25, Greg KH wrote:
On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote:
On 11. 05. 20, 9:39, Greg KH wrote:
> On Mon, May 11, 2020 at 12:23:58AM -0700, rana...@codeaurora.org wrote:
>> On 2020-05-09 23:48, Greg KH wrote:
>>> On Sat, May 09, 2020 at 06:30:56PM -0700, rana...@codeaurora.org wrote:
On 2020-05-06 02:48, Greg KH wrote:
> On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
>> Potentially, hvc_open() can be called in parallel when two tasks calls
>> open() on /dev/hvcX. In such a scenario, if the
>> hp->ops->notifier_add()
>> callback in the function fails, where it sets the tty->driver_data to
>> NULL, the parallel hvc_open() can see this NULL and cause a memory
>> abort.
>> Hence, serialize hvc_open and check if tty->private_data is NULL
>> before
>> proceeding ahead.
>>
>> The issue can be easily reproduced by launching two tasks
>> simultaneously
>> that does nothing but open() and close() on /dev/hvcX.
>> For example:
>> $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
>>
>> Signed-off-by: Raghavendra Rao Ananta
>> ---
>> drivers/tty/hvc/hvc_console.c | 16 ++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/hvc/hvc_console.c
>> b/drivers/tty/hvc/hvc_console.c
>> index 436cc51c92c3..ebe26fe5ac09 100644
>> --- a/drivers/tty/hvc/hvc_console.c
>> +++ b/drivers/tty/hvc/hvc_console.c
>> @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
>> */
>> static DEFINE_MUTEX(hvc_structs_mutex);
>>
>> +/* Mutex to serialize hvc_open */
>> +static DEFINE_MUTEX(hvc_open_mutex);
>> /*
>> * This value is used to assign a tty->index value to a hvc_struct
>> based
>> * upon order of exposure via hvc_probe(), when we can not match it
>> to
>> @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
>> *driver, struct tty_struct *tty)
>> */
>> static int hvc_open(struct tty_struct *tty, struct file * filp)
>> {
>> - struct hvc_struct *hp = tty->driver_data;
>> + struct hvc_struct *hp;
>>unsigned long flags;
>>int rc = 0;
>>
>> + mutex_lock(&hvc_open_mutex);
>> +
>> + hp = tty->driver_data;
>> + if (!hp) {
>> + rc = -EIO;
>> + goto out;
>> + }
>> +
>>spin_lock_irqsave(&hp->port.lock, flags);
>>/* Check and then increment for fast path open. */
>>if (hp->port.count++ > 0) {
>>spin_unlock_irqrestore(&hp->port.lock, flags);
>>hvc_kick();
>> - return 0;
>> + goto out;
>>} /* else count == 0 */
>>spin_unlock_irqrestore(&hp->port.lock, flags);
>
> Wait, why isn't this driver just calling tty_port_open() instead of
> trying to open-code all of this?
>
> Keeping a single mutext for open will not protect it from close, it will
> just slow things down a bit. There should already be a tty lock held by
> the tty core for open() to keep it from racing things, right?
The tty lock should have been held, but not likely across
->install() and
->open() callbacks, thus resulting in a race between hvc_install() and
hvc_open(),
>>>
>>> How? The tty lock is held in install, and should not conflict with
>>> open(), otherwise, we would be seeing this happen in all tty drivers,
>>> right?
>>>
>> Well, I was expecting the same, but IIRC, I see that the open() was being
>> called in parallel for the same device node.
>
> So open and install are happening at the same time? And the tty_lock()
> does not protect the needed fields from being protected properly? If
> not, what fields are being touched without the lock?
>
>> Is it expected that the tty core would allow only one thread to
>> access the dev-node, while blocking the other, or is it the client
>> driver's responsibility to handle the exclusiveness?
>
> The tty core should handle this correctly, for things that can mess
> stuff up (like install and open at the same time). A driver should not
> have to worry about that.
>
where hvc_install() sets a data and the hvc_open() clears it.
hvc_open()
doesn't
check if the data was set to NULL and proceeds.
>>>
>>> What data is being set that hvc_open is checking?
>> hvc_install sets tty->private_data to hp, while hvc_open sets it to NULL (in
>> one of the paths).
>
> I see no use of private_data in drivers/tty/hvc/ so what exactly are you
> referring to?
He likely means tty->driver_data. And there exactly lays the issue.
commit bdb498c20040616e94b05c31a0ceb3e134b7e829
Author: Jiri Slaby
Date: Tue Aug 7 21:48:04 2012 +0200
TTY: hvc_console, add tty install
added hvc_install but did not move 'tty->driver_data =
Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-13 00:04, Greg KH wrote:
On Tue, May 12, 2020 at 02:39:50PM -0700, rana...@codeaurora.org wrote:
On 2020-05-12 01:25, Greg KH wrote:
> On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote:
> > On 11. 05. 20, 9:39, Greg KH wrote:
> > > On Mon, May 11, 2020 at 12:23:58AM -0700, rana...@codeaurora.org wrote:
> > >> On 2020-05-09 23:48, Greg KH wrote:
> > >>> On Sat, May 09, 2020 at 06:30:56PM -0700, rana...@codeaurora.org wrote:
> > On 2020-05-06 02:48, Greg KH wrote:
> > > On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta
wrote:
> > >> Potentially, hvc_open() can be called in parallel when two tasks
calls
> > >> open() on /dev/hvcX. In such a scenario, if the
> > >> hp->ops->notifier_add()
> > >> callback in the function fails, where it sets the tty->driver_data to
> > >> NULL, the parallel hvc_open() can see this NULL and cause a memory
> > >> abort.
> > >> Hence, serialize hvc_open and check if tty->private_data is NULL
> > >> before
> > >> proceeding ahead.
> > >>
> > >> The issue can be easily reproduced by launching two tasks
> > >> simultaneously
> > >> that does nothing but open() and close() on /dev/hvcX.
> > >> For example:
> > >> $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
> > >>
> > >> Signed-off-by: Raghavendra Rao Ananta
> > >> ---
> > >> drivers/tty/hvc/hvc_console.c | 16 ++--
> > >> 1 file changed, 14 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/drivers/tty/hvc/hvc_console.c
> > >> b/drivers/tty/hvc/hvc_console.c
> > >> index 436cc51c92c3..ebe26fe5ac09 100644
> > >> --- a/drivers/tty/hvc/hvc_console.c
> > >> +++ b/drivers/tty/hvc/hvc_console.c
> > >> @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
> > >> */
> > >> static DEFINE_MUTEX(hvc_structs_mutex);
> > >>
> > >> +/* Mutex to serialize hvc_open */
> > >> +static DEFINE_MUTEX(hvc_open_mutex);
> > >> /*
> > >> * This value is used to assign a tty->index value to a hvc_struct
> > >> based
> > >> * upon order of exposure via hvc_probe(), when we can not match it
> > >> to
> > >> @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
> > >> *driver, struct tty_struct *tty)
> > >> */
> > >> static int hvc_open(struct tty_struct *tty, struct file * filp)
> > >> {
> > >> -struct hvc_struct *hp = tty->driver_data;
> > >> +struct hvc_struct *hp;
> > >> unsigned long flags;
> > >> int rc = 0;
> > >>
> > >> +mutex_lock(&hvc_open_mutex);
> > >> +
> > >> +hp = tty->driver_data;
> > >> +if (!hp) {
> > >> +rc = -EIO;
> > >> +goto out;
> > >> +}
> > >> +
> > >> spin_lock_irqsave(&hp->port.lock, flags);
> > >> /* Check and then increment for fast path open. */
> > >> if (hp->port.count++ > 0) {
> > >> spin_unlock_irqrestore(&hp->port.lock, flags);
> > >> hvc_kick();
> > >> -return 0;
> > >> +goto out;
> > >> } /* else count == 0 */
> > >> spin_unlock_irqrestore(&hp->port.lock, flags);
> > >
> > > Wait, why isn't this driver just calling tty_port_open() instead of
> > > trying to open-code all of this?
> > >
> > > Keeping a single mutext for open will not protect it from close, it
will
> > > just slow things down a bit. There should already be a tty lock held
by
> > > the tty core for open() to keep it from racing things, right?
> > The tty lock should have been held, but not likely across
> > ->install() and
> > ->open() callbacks, thus resulting in a race between hvc_install() and
> > hvc_open(),
> > >>>
> > >>> How? The tty lock is held in install, and should not conflict with
> > >>> open(), otherwise, we would be seeing this happen in all tty drivers,
> > >>> right?
> > >>>
> > >> Well, I was expecting the same, but IIRC, I see that the open() was being
> > >> called in parallel for the same device node.
> > >
> > > So open and install are happening at the same time? And the tty_lock()
> > > does not protect the needed fields from being protected properly? If
> > > not, what fields are being touched without the lock?
> > >
> > >> Is it expected that the tty core would allow only one thread to
> > >> access the dev-node, while blocking the other, or is it the client
> > >> driver's responsibility to handle the exclusiveness?
> > >
> > > The tty core should handle this correctly, for things that can mess
> > > stuff up (like install and open at the same time). A driver should not
> > > have to worry about that.
> > >
> > where hvc_install() sets a data and the hvc_open() clears it.
> > hvc_open()
> > doesn't
> > check if the data was set to NULL and proceeds.
> > >>>
> > >>> What data i
Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-15 00:30, Greg KH wrote:
On Thu, May 14, 2020 at 04:22:10PM -0700, rana...@codeaurora.org wrote:
On 2020-05-13 00:04, Greg KH wrote:
> On Tue, May 12, 2020 at 02:39:50PM -0700, rana...@codeaurora.org wrote:
> > On 2020-05-12 01:25, Greg KH wrote:
> > > On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote:
> > > > On 11. 05. 20, 9:39, Greg KH wrote:
> > > > > On Mon, May 11, 2020 at 12:23:58AM -0700, rana...@codeaurora.org
wrote:
> > > > >> On 2020-05-09 23:48, Greg KH wrote:
> > > > >>> On Sat, May 09, 2020 at 06:30:56PM -0700, rana...@codeaurora.org
wrote:
> > > > On 2020-05-06 02:48, Greg KH wrote:
> > > > > On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta
wrote:
> > > > >> Potentially, hvc_open() can be called in parallel when two tasks
calls
> > > > >> open() on /dev/hvcX. In such a scenario, if the
> > > > >> hp->ops->notifier_add()
> > > > >> callback in the function fails, where it sets the
tty->driver_data to
> > > > >> NULL, the parallel hvc_open() can see this NULL and cause a
memory
> > > > >> abort.
> > > > >> Hence, serialize hvc_open and check if tty->private_data is NULL
> > > > >> before
> > > > >> proceeding ahead.
> > > > >>
> > > > >> The issue can be easily reproduced by launching two tasks
> > > > >> simultaneously
> > > > >> that does nothing but open() and close() on /dev/hvcX.
> > > > >> For example:
> > > > >> $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
> > > > >>
> > > > >> Signed-off-by: Raghavendra Rao Ananta
> > > > >> ---
> > > > >> drivers/tty/hvc/hvc_console.c | 16 ++--
> > > > >> 1 file changed, 14 insertions(+), 2 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/tty/hvc/hvc_console.c
> > > > >> b/drivers/tty/hvc/hvc_console.c
> > > > >> index 436cc51c92c3..ebe26fe5ac09 100644
> > > > >> --- a/drivers/tty/hvc/hvc_console.c
> > > > >> +++ b/drivers/tty/hvc/hvc_console.c
> > > > >> @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
> > > > >> */
> > > > >> static DEFINE_MUTEX(hvc_structs_mutex);
> > > > >>
> > > > >> +/* Mutex to serialize hvc_open */
> > > > >> +static DEFINE_MUTEX(hvc_open_mutex);
> > > > >> /*
> > > > >> * This value is used to assign a tty->index value to a
hvc_struct
> > > > >> based
> > > > >> * upon order of exposure via hvc_probe(), when we can not
match it
> > > > >> to
> > > > >> @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
> > > > >> *driver, struct tty_struct *tty)
> > > > >> */
> > > > >> static int hvc_open(struct tty_struct *tty, struct file * filp)
> > > > >> {
> > > > >> - struct hvc_struct *hp = tty->driver_data;
> > > > >> + struct hvc_struct *hp;
> > > > >>unsigned long flags;
> > > > >>int rc = 0;
> > > > >>
> > > > >> + mutex_lock(&hvc_open_mutex);
> > > > >> +
> > > > >> + hp = tty->driver_data;
> > > > >> + if (!hp) {
> > > > >> + rc = -EIO;
> > > > >> + goto out;
> > > > >> + }
> > > > >> +
> > > > >>spin_lock_irqsave(&hp->port.lock, flags);
> > > > >>/* Check and then increment for fast path open. */
> > > > >>if (hp->port.count++ > 0) {
> > > > >>spin_unlock_irqrestore(&hp->port.lock, flags);
> > > > >>hvc_kick();
> > > > >> - return 0;
> > > > >> + goto out;
> > > > >>} /* else count == 0 */
> > > > >>spin_unlock_irqrestore(&hp->port.lock, flags);
> > > > >
> > > > > Wait, why isn't this driver just calling tty_port_open() instead
of
> > > > > trying to open-code all of this?
> > > > >
> > > > > Keeping a single mutext for open will not protect it from close,
it will
> > > > > just slow things down a bit. There should already be a tty lock
held by
> > > > > the tty core for open() to keep it from racing things, right?
> > > > The tty lock should have been held, but not likely across
> > > > ->install() and
> > > > ->open() callbacks, thus resulting in a race between hvc_install()
and
> > > > hvc_open(),
> > > > >>>
> > > > >>> How? The tty lock is held in install, and should not conflict with
> > > > >>> open(), otherwise, we would be seeing this happen in all tty
drivers,
> > > > >>> right?
> > > > >>>
> > > > >> Well, I was expecting the same, but IIRC, I see that the open() was
being
> > > > >> called in parallel for the same device node.
> > > > >
> > > > > So open and install are happening at the same time? And the
tty_lock()
> > > > > does not protect the needed fields from being protected properly? If
> > > > > not, what fields are being touched without the lock?
> > > > >
> > > > >> Is it expected that the tty core would allow only one thread to
> > > > >> access the dev-node, while blocking the othe
Re: [PATCH v2] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-20 01:59, Jiri Slaby wrote: On 20. 05. 20, 8:47, Raghavendra Rao Ananta wrote: Potentially, hvc_open() can be called in parallel when two tasks calls open() on /dev/hvcX. In such a scenario, if the hp->ops->notifier_add() callback in the function fails, where it sets the tty->driver_data to NULL, the parallel hvc_open() can see this NULL and cause a memory abort. Hence, do a NULL check at the beginning, before proceeding ahead. The issue can be easily reproduced by launching two tasks simultaneously that does an open() call on /dev/hvcX. For example: $ cat /dev/hvc0 & cat /dev/hvc0 & Cc: sta...@vger.kernel.org Signed-off-by: Raghavendra Rao Ananta --- drivers/tty/hvc/hvc_console.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index 436cc51c92c3..80709f754cc8 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -350,6 +350,9 @@ static int hvc_open(struct tty_struct *tty, struct file * filp) unsigned long flags; int rc = 0; + if (!hp) + return -ENODEV; + This is still not fixing the bug properly. See: https://lore.kernel.org/linuxppc-dev/0f7791f5-0a53-59f6-7277-247a789f3...@suse.cz/ In particular, the paragraph starting "IOW". You are right. This doesn't fix the problem entirely. There are other parts to it which is not handled in a clean way by the driver. Apart from the things you've mentioned, it doesn't seem to handle the hp->port.count correctly as well. hvc_open: hp->port.count++ hp->ops->notifier_add(hp, hp->data) fails tty->driver_data = NULL hvc_close: returns immediately as tty->driver_data == NULL, without hp->port.count-- This would leave the port in a stale state, and the second caller of hvc_open doesn't get a chance to call/retry hp->ops->notifier_add(hp, hp->data); However, the patch is not trying to address the logical issues with hvc_open and hvc_close. It's only trying to eliminate the potential NULL pointer dereference, leading to a panic. From what I see, the hvc_open is serialized by tty_lock, and adding a NULL check here is preventing the second caller. thanks, Thank you. Raghavendra
Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
On 2020-05-20 02:38, Jiri Slaby wrote: On 15. 05. 20, 1:22, rana...@codeaurora.org wrote: On 2020-05-13 00:04, Greg KH wrote: On Tue, May 12, 2020 at 02:39:50PM -0700, rana...@codeaurora.org wrote: On 2020-05-12 01:25, Greg KH wrote: > On Tue, May 12, 2020 at 09:22:15AM +0200, Jiri Slaby wrote: > > commit bdb498c20040616e94b05c31a0ceb3e134b7e829 > > Author: Jiri Slaby > > Date: Tue Aug 7 21:48:04 2012 +0200 > > > > TTY: hvc_console, add tty install > > > > added hvc_install but did not move 'tty->driver_data = NULL;' from > > hvc_open's fail path to hvc_cleanup. > > > > IOW hvc_open now NULLs tty->driver_data even for another task which > > opened the tty earlier. The same holds for > > "tty_port_tty_set(&hp->port, > > NULL);" there. And actually "tty_port_put(&hp->port);" is also > > incorrect > > for the 2nd task opening the tty. > > ... These are the traces you get when the issue happens: [ 154.212291] hvc_install called for pid: 666 [ 154.216705] hvc_open called for pid: 666 [ 154.233657] hvc_open: request_irq failed with rc -22. [ 154.238934] hvc_open called for pid: 678 [ 154.243012] Unable to handle kernel NULL pointer dereference at virtual address 00c4 # hvc_install isn't called for pid: 678 as the file wasn't closed yet. Nice. Does the attached help? Yeah, it looks good. I think it also eliminates the port.count reference issue discussed on the v2 patch. Are you planning to mainline this? I wonder how comes the tty_port_put in hvc_open does not cause a UAF? I would say hvc_open fails, tty_port_put is called. It decrements the reference taken in hvc_install. So far so good. Now, this should happen IMO: tty_open -> hvc_open (fails) -> tty_port_put hvc_console driver defines port->ops->destruct(). Upon tty_port_put(), the tty_port_destructor() calls port->ops->destruct(), rather than kfree(port). -> tty_release -> tty_release_struct -> tty_kref_put -> queue_release_one_tty SCHEDULED WORKQUEUE release_one_tty -> hvc_cleanup -> tty_port_put (should die terrible death now) Since port is not free'd, I think we should be good. What am I missing? thanks, Thank you. Raghavendra
