Hi Alan !
(Asking you since I know you did some TTY locking work a while ago).
I noticed that there doesn't seem to be any kind of locking in
tty_(un)register_driver. It can very easily race with tty_open() doing a
get_tty_driver(). Shouldn't tty_(un)register_driver be changed to take
the tty_sem at least while manipulating the list ?
I noticed that while chasing a different bug (a driver bug actually),
but I don't see how we are protected here. And considering the race I
found in the driver, I tend to think we aren't protected at all
FYI. The hvc driver issue was basically that it was allowing struct
console->device (the kernel console callback to link to the tty driver)
to return the tty_driver pointer before it called tty_register_driver,
thus a racing tty_open() of the default console was blow up accessing
driver->ttys.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
