* tty: tty_open can return to userspace holding tty_mutex
@ 2009-01-26 21:02 Eric Paris
2009-01-26 21:16 ` Alan Cox
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Eric Paris @ 2009-01-26 21:02 UTC (permalink / raw)
To: linux-kernel; +Cc: sgrubb, esandeen, sukadev, alan
__tty_open could return (to userspace) holding the tty_mutex thanks to a
regression introduced by 4a2b5fddd53b80efcb3266ee36e23b8de28e761a. This was
found by bisecting an fsfuzzer problem. Admittedly I have no idea how it
managed to tickle this 100% reliably, but it is clearly a regression and
when hit leaves the box in a completely unusable state. This patch lets
the fsfuzzer test complete every time.
Signed-off-by: Eric Paris <eparis@redhat.com>
---
drivers/char/tty_io.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index d33e5ab..bc84e12 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1817,8 +1817,10 @@ got_driver:
/* check whether we're reopening an existing tty */
tty = tty_driver_lookup_tty(driver, inode, index);
- if (IS_ERR(tty))
+ if (IS_ERR(tty)) {
+ mutex_unlock(&tty_mutex);
return PTR_ERR(tty);
+ }
}
if (tty) {
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: tty: tty_open can return to userspace holding tty_mutex
2009-01-26 21:02 tty: tty_open can return to userspace holding tty_mutex Eric Paris
@ 2009-01-26 21:16 ` Alan Cox
2009-01-26 21:19 ` Michael Tokarev
2009-01-26 21:47 ` Sukadev Bhattiprolu
2 siblings, 0 replies; 4+ messages in thread
From: Alan Cox @ 2009-01-26 21:16 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-kernel, sgrubb, esandeen, sukadev
On Mon, 26 Jan 2009 16:02:40 -0500
Eric Paris <eparis@redhat.com> wrote:
> __tty_open could return (to userspace) holding the tty_mutex thanks to a
> regression introduced by 4a2b5fddd53b80efcb3266ee36e23b8de28e761a. This was
> found by bisecting an fsfuzzer problem. Admittedly I have no idea how it
> managed to tickle this 100% reliably, but it is clearly a regression and
> when hit leaves the box in a completely unusable state. This patch lets
> the fsfuzzer test complete every time.
Well spotted, and will go fix now. I think your fsfuzzer created a device
node for an out of range tty subdevice
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: tty: tty_open can return to userspace holding tty_mutex
2009-01-26 21:02 tty: tty_open can return to userspace holding tty_mutex Eric Paris
2009-01-26 21:16 ` Alan Cox
@ 2009-01-26 21:19 ` Michael Tokarev
2009-01-26 21:47 ` Sukadev Bhattiprolu
2 siblings, 0 replies; 4+ messages in thread
From: Michael Tokarev @ 2009-01-26 21:19 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-kernel, sgrubb, esandeen, sukadev, alan
Eric Paris wrote:
> __tty_open could return (to userspace) holding the tty_mutex thanks to a
> regression introduced by 4a2b5fddd53b80efcb3266ee36e23b8de28e761a. This was
> found by bisecting an fsfuzzer problem. Admittedly I have no idea how it
> managed to tickle this 100% reliably, but it is clearly a regression and
> when hit leaves the box in a completely unusable state. This patch lets
> the fsfuzzer test complete every time.
This should go to -stable too, right?
It's present in 2.6.28 (but not 2.6.27).
/mjt
> Signed-off-by: Eric Paris <eparis@redhat.com>
>
> ---
> drivers/char/tty_io.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
> index d33e5ab..bc84e12 100644
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -1817,8 +1817,10 @@ got_driver:
> /* check whether we're reopening an existing tty */
> tty = tty_driver_lookup_tty(driver, inode, index);
>
> - if (IS_ERR(tty))
> + if (IS_ERR(tty)) {
> + mutex_unlock(&tty_mutex);
> return PTR_ERR(tty);
> + }
> }
>
> if (tty) {
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: tty: tty_open can return to userspace holding tty_mutex
2009-01-26 21:02 tty: tty_open can return to userspace holding tty_mutex Eric Paris
2009-01-26 21:16 ` Alan Cox
2009-01-26 21:19 ` Michael Tokarev
@ 2009-01-26 21:47 ` Sukadev Bhattiprolu
2 siblings, 0 replies; 4+ messages in thread
From: Sukadev Bhattiprolu @ 2009-01-26 21:47 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-kernel, sgrubb, esandeen, sukadev, alan
Eric Paris [eparis@redhat.com] wrote:
| __tty_open could return (to userspace) holding the tty_mutex thanks to a
| regression introduced by 4a2b5fddd53b80efcb3266ee36e23b8de28e761a. This was
| found by bisecting an fsfuzzer problem. Admittedly I have no idea how it
| managed to tickle this 100% reliably, but it is clearly a regression and
| when hit leaves the box in a completely unusable state. This patch lets
| the fsfuzzer test complete every time.
Good catch.
|
| Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
|
| ---
| drivers/char/tty_io.c | 4 +++-
| 1 files changed, 3 insertions(+), 1 deletions(-)
|
| diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
| index d33e5ab..bc84e12 100644
| --- a/drivers/char/tty_io.c
| +++ b/drivers/char/tty_io.c
| @@ -1817,8 +1817,10 @@ got_driver:
| /* check whether we're reopening an existing tty */
| tty = tty_driver_lookup_tty(driver, inode, index);
|
| - if (IS_ERR(tty))
| + if (IS_ERR(tty)) {
| + mutex_unlock(&tty_mutex);
| return PTR_ERR(tty);
| + }
| }
|
| if (tty) {
|
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-01-26 21:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-26 21:02 tty: tty_open can return to userspace holding tty_mutex Eric Paris
2009-01-26 21:16 ` Alan Cox
2009-01-26 21:19 ` Michael Tokarev
2009-01-26 21:47 ` Sukadev Bhattiprolu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox