__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 <[email protected]>
---
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) {
On Mon, 26 Jan 2009 16:02:40 -0500
Eric Paris <[email protected]> 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
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 <[email protected]>
>
> ---
> 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) {
Eric Paris [[email protected]] 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 <[email protected]>
Acked-by: Sukadev Bhattiprolu <[email protected]>
|
| ---
| 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) {
|