Re: PATCH against 2.4.2: TTY hangup on PPP channel corrupts kernel memory

[Paul Fulghum]

From: "Andrew Morton" <[e-mail]>

> Your analysis is correct.  It's a bug.
> 
> Furthermore, n_hdlc_tty_open() (for example) can sleep prior to
> incrementing the module refcount, which means the module can be
> unloaded while it's running.  I cut a patch ages ago which fixes
> this one for both ttys and ldiscs.  I never got around to sending
> it to anyone.
> 
> > Does this mean that all line discipline implementations must use a
> > spinlock around critical code in "open", "close", and every other line
> > discipline function?  It looks like they must, and it looks like most
> > don't right now.

I have experienced essentially the same problem:
A line discipline can be switched while a user mode program is blocked
inside of a line discipline call.

In my case the call was ioctl() (select) which went through the ldisc
(n_hdlc) and was being serviced by (and blocked in) the tty layer. 

Two processes had the underlying serial device open. One process
restored the ldisc to N_TTY, exited, and the script that started
the process unloaded the ldisc driver (which had
a zero ref count as a result of being switched out).
When the select call of the other process tried to return
(to the n_hdlc ldisc), the code was already unloaded and an
oops occurred.

I was not too worried about this because it was caused by
a series of wrong (buggy) moves by the user mode processes.

But it goes back to the problem of allowing the ldisc to
change when there are existing calls blocked in (or through)
the ldisc. 

Paul Fulghum [e-mail]
Microgate Corporation www.microgate.com