Commit 82e61c3
vt: keyboard, extend func_buf_lock to readers
Both read-side users of func_table/func_buf need locking. Without that,
one can easily confuse the code by repeatedly setting altering strings
like:
while (1)
for (a = 0; a < 2; a++) {
struct kbsentry kbs = {};
strcpy((char *)kbs.kb_string, a ? ".\n" : "88888\n");
ioctl(fd, KDSKBSENT, &kbs);
}
When that program runs, one can get unexpected output by holding F1
(note the unxpected period on the last line):
.
88888
.8888
So protect all accesses to 'func_table' (and func_buf) by preexisting
'func_buf_lock'.
It is easy in 'k_fn' handler as 'puts_queue' is expected not to sleep.
On the other hand, KDGKBSENT needs a local (atomic) copy of the string
because copy_to_user can sleep. Use already allocated, but unused
'kbs->kb_string' for that purpose.
Note that the program above needs at least CAP_SYS_TTY_CONFIG.
This depends on the previous patch and on the func_buf_lock lock added
in commit 46ca3f7 (tty/vt: fix write/write race in ioctl(KDSKBSENT)
handler) in 5.2.
Likely fixes CVE-2020-25656.
Cc: <stable@vger.kernel.org>
Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Link: https://lore.kernel.org/r/20201019085517.10176-2-jslaby@suse.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>1 parent 6ca03f9 commit 82e61c3
1 file changed
Lines changed: 13 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
743 | 743 | | |
744 | 744 | | |
745 | 745 | | |
| 746 | + | |
| 747 | + | |
| 748 | + | |
746 | 749 | | |
747 | 750 | | |
| 751 | + | |
| 752 | + | |
748 | 753 | | |
749 | 754 | | |
750 | 755 | | |
| |||
1991 | 1996 | | |
1992 | 1997 | | |
1993 | 1998 | | |
1994 | | - | |
| 1999 | + | |
1995 | 2000 | | |
1996 | 2001 | | |
1997 | 2002 | | |
| |||
2023 | 2028 | | |
2024 | 2029 | | |
2025 | 2030 | | |
2026 | | - | |
| 2031 | + | |
| 2032 | + | |
| 2033 | + | |
| 2034 | + | |
| 2035 | + | |
2027 | 2036 | | |
2028 | | - | |
2029 | | - | |
| 2037 | + | |
| 2038 | + | |
2030 | 2039 | | |
2031 | 2040 | | |
2032 | 2041 | | |
| |||
0 commit comments