| Message ID | 20220923223123.410035-1-cengiz.can@canonical.com |
|---|---|
| Headers | show |
| Series | UBUNTU: SAUCE: fbdev: remove redundant lock_fb_info | expand |
On Sat, Sep 24, 2022 at 01:31:23AM +0300, Cengiz Can wrote: > BugLink: https://bugs.launchpad.net/bugs/1990690 > > SRU Justification: > > [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. > > 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 > ``` > > [Test case] > Ran a sample framebuffer userspace test which calls FBIOPUT_VSCREENINFO. > > Verified that deadlock is producible. > > After removing redundant lock_fb_info, same test program no longer > causes a deadlock. > > [Potential regressions] > There are no new potential regressions. > > Cengiz Can (1): > UBUNTU: SAUCE: fbdev: remove redundant lock_fb_info > > drivers/video/fbdev/core/fbmem.c | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Cory Todd <cory.todd@canonical.com> - corytodd
On 9/23/22 16:31, Cengiz Can wrote: > BugLink: https://bugs.launchpad.net/bugs/1990690 > > SRU Justification: > > [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. > > 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 > ``` > > [Test case] > Ran a sample framebuffer userspace test which calls FBIOPUT_VSCREENINFO. > > Verified that deadlock is producible. > > After removing redundant lock_fb_info, same test program no longer > causes a deadlock. > > [Potential regressions] > There are no new potential regressions. > > Cengiz Can (1): > UBUNTU: SAUCE: fbdev: remove redundant lock_fb_info > > drivers/video/fbdev/core/fbmem.c | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Tim Gardner <tim.gardner@canonical.com>
Applied to bionic/linux master-next, I left the commit header and message alone as it mentions the deadlock which is what we care about. Thanks! - Luke On Fri, Sep 23, 2022 at 3:32 PM Cengiz Can <cengiz.can@canonical.com> wrote: > BugLink: https://bugs.launchpad.net/bugs/1990690 > > SRU Justification: > > [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. > > 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 > ``` > > [Test case] > Ran a sample framebuffer userspace test which calls FBIOPUT_VSCREENINFO. > > Verified that deadlock is producible. > > After removing redundant lock_fb_info, same test program no longer > causes a deadlock. > > [Potential regressions] > There are no new potential regressions. > > Cengiz Can (1): > UBUNTU: SAUCE: fbdev: remove redundant lock_fb_info > > drivers/video/fbdev/core/fbmem.c | 1 - > 1 file changed, 1 deletion(-) > > -- > 2.34.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team >
BugLink: https://bugs.launchpad.net/bugs/1990690 SRU Justification: [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. 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 ``` [Test case] Ran a sample framebuffer userspace test which calls FBIOPUT_VSCREENINFO. Verified that deadlock is producible. After removing redundant lock_fb_info, same test program no longer causes a deadlock. [Potential regressions] There are no new potential regressions. Cengiz Can (1): UBUNTU: SAUCE: fbdev: remove redundant lock_fb_info drivers/video/fbdev/core/fbmem.c | 1 - 1 file changed, 1 deletion(-)