Public bug reported:
[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.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Invalid
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Cengiz Can (cengizcan)
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Importance: Medium => Undecided
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Status: New => Invalid
** Changed in: linux (Ubuntu Bionic)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1990690
Title:
Users belonging to video group may trigger a deadlock WARN
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Bionic:
In Progress
Bug 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1990690/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
