| 2022-09-27 01:54:33 |
Cengiz Can |
description |
[Impact]
One of the fixing commits for CVE-2021-33655, commit 159a96b199b4
("fbcon: Prevent that screen size is smaller than font size") introduced
a redundant lock_fb_info line into the ioctl flow in fbmem.c.
This line only exists in bionic tree.
Users belonging to video group may trigger a deadlock and potentially
lock the system.
============================================
WARNING: possible recursive locking detected
4.15.0-195-generic #206 Not tainted
--------------------------------------------
refresh/1248 is trying to acquire lock:
(&fb_info->lock){+.+.}, at: [<000000004c154cfe>] lock_fb_info+0x1d/0x40
but task is already holding lock:
(&fb_info->lock){+.+.}, at: [<000000004c154cfe>] lock_fb_info+0x1d/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&fb_info->lock);
lock(&fb_info->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by refresh/1248:
#0: (console_lock){+.+.}, at: [<000000008000aa2b>] do_fb_ioctl+0x435/0x5e0
#1: (&fb_info->lock){+.+.}, at: [<000000004c154cfe>] lock_fb_info+0x1d/0x40
stack backtrace:
CPU: 0 PID: 1248 Comm: refresh Not tainted 4.15.0-195-generic #206
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Call Trace:
dump_stack+0x98/0xd2
__lock_acquire+0x736/0x1480
? sched_clock_local+0x17/0x90
? sched_clock+0x9/0x10
? sched_clock_local+0x17/0x90
lock_acquire+0xa3/0x1e0
? lock_acquire+0xa3/0x1e0
? lock_fb_info+0x1d/0x40
? lock_fb_info+0x1d/0x40
__mutex_lock+0x65/0x970
? lock_fb_info+0x1d/0x40
? sched_clock_local+0x17/0x90
? lock_acquire+0xa3/0x1e0
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
lock_fb_info+0x1d/0x40
do_fb_ioctl+0x57a/0x5e0
? __fd_install+0x5/0x250
fb_ioctl+0x33/0x40
? fb_ioctl+0x33/0x40
do_vfs_ioctl+0xa9/0x6d0
? putname+0x4c/0x60
? do_sys_open+0x13d/0x370
SyS_ioctl+0x79/0x90
do_syscall_64+0x7b/0x1e0
entry_SYSCALL_64_after_hwframe+0x46/0xbb
RIP: 0033:0x7f22acca7217
RSP: 002b:00007ffe2a930b48 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f22acca7217
RDX: 00007ffe2a930c30 RSI: 0000000000004601 RDI: 0000000000000003
RBP: 00007ffe2a930d40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000213 R12: 00005624ac8fc7c0
R13: 00007ffe2a930e20 R14: 0000000000000000 R15: 0000000000000000
[Test case]
Run a sample framebuffer userspace test to call FBIOPUT_VSCREENINFO
and verified with LOCKDEP.
[Potential regressions]
There are no new potential regressions. |
[Impact]
One of the fixing commits for CVE-2021-33655, commit 159a96b199b4
("fbcon: Prevent that screen size is smaller than font size") introduced
an extraneous lock_fb_info line into the ioctl flow in fbmem.c.
This line only exists in bionic tree.
Users belonging to video group may trigger a deadlock and potentially
lock the system.
============================================
WARNING: possible recursive locking detected
4.15.0-195-generic #206 Not tainted
--------------------------------------------
refresh/1248 is trying to acquire lock:
(&fb_info->lock){+.+.}, at: [<000000004c154cfe>] lock_fb_info+0x1d/0x40
but task is already holding lock:
(&fb_info->lock){+.+.}, at: [<000000004c154cfe>] lock_fb_info+0x1d/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&fb_info->lock);
lock(&fb_info->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by refresh/1248:
#0: (console_lock){+.+.}, at: [<000000008000aa2b>] do_fb_ioctl+0x435/0x5e0
#1: (&fb_info->lock){+.+.}, at: [<000000004c154cfe>] lock_fb_info+0x1d/0x40
stack backtrace:
CPU: 0 PID: 1248 Comm: refresh Not tainted 4.15.0-195-generic #206
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
Call Trace:
dump_stack+0x98/0xd2
__lock_acquire+0x736/0x1480
? sched_clock_local+0x17/0x90
? sched_clock+0x9/0x10
? sched_clock_local+0x17/0x90
lock_acquire+0xa3/0x1e0
? lock_acquire+0xa3/0x1e0
? lock_fb_info+0x1d/0x40
? lock_fb_info+0x1d/0x40
__mutex_lock+0x65/0x970
? lock_fb_info+0x1d/0x40
? sched_clock_local+0x17/0x90
? lock_acquire+0xa3/0x1e0
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
lock_fb_info+0x1d/0x40
do_fb_ioctl+0x57a/0x5e0
? __fd_install+0x5/0x250
fb_ioctl+0x33/0x40
? fb_ioctl+0x33/0x40
do_vfs_ioctl+0xa9/0x6d0
? putname+0x4c/0x60
? do_sys_open+0x13d/0x370
SyS_ioctl+0x79/0x90
do_syscall_64+0x7b/0x1e0
entry_SYSCALL_64_after_hwframe+0x46/0xbb
RIP: 0033:0x7f22acca7217
RSP: 002b:00007ffe2a930b48 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f22acca7217
RDX: 00007ffe2a930c30 RSI: 0000000000004601 RDI: 0000000000000003
RBP: 00007ffe2a930d40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000213 R12: 00005624ac8fc7c0
R13: 00007ffe2a930e20 R14: 0000000000000000 R15: 0000000000000000
[Test case]
Run a sample framebuffer userspace test to call FBIOPUT_VSCREENINFO
and verified with LOCKDEP.
[Potential regressions]
There are no new potential regressions. |
|
