[Kernel-packages] [Bug 2017013] Re: net: sched: Fix use after free in red_enqueue()
** Changed in: linux-oem-5.17 (Ubuntu)
Status: In Progress => Fix Committed
** Changed in: linux-oem-5.17 (Ubuntu)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu Xenial)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
--
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/2017013
Title:
net: sched: Fix use after free in red_enqueue()
Status in linux package in Ubuntu:
Fix Released
Status in linux-oem-5.14 package in Ubuntu:
Won't Fix
Status in linux-oem-5.17 package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Fix Released
Bug description:
[Impact]
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
[Fix]
Cherry picked from upstream.
[Test case]
Compile, boot and basic network functionality tested using ntop.
[Potential regression]
Low. This has been in multiple trees for a while now.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2017013/+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
[Kernel-packages] [Bug 2017013] Re: net: sched: Fix use after free in red_enqueue()
** Changed in: linux (Ubuntu)
Status: Incomplete => Fix Committed
** Changed in: linux (Ubuntu)
Importance: Undecided => High
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Cengiz Can (cengizcan)
--
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/2017013
Title:
net: sched: Fix use after free in red_enqueue()
Status in linux package in Ubuntu:
Fix Committed
Status in linux-oem-5.14 package in Ubuntu:
In Progress
Status in linux-oem-5.17 package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Fix Committed
Bug description:
[Impact]
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
[Fix]
Cherry picked from upstream.
[Test case]
Compile, boot and basic network functionality tested using ntop.
[Potential regression]
Low. This has been in multiple trees for a while now.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2017013/+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
[Kernel-packages] [Bug 2017013] Re: net: sched: Fix use after free in red_enqueue()
** Changed in: linux (Ubuntu Xenial)
Status: In Progress => Fix Committed
--
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/2017013
Title:
net: sched: Fix use after free in red_enqueue()
Status in linux package in Ubuntu:
Incomplete
Status in linux-oem-5.14 package in Ubuntu:
In Progress
Status in linux-oem-5.17 package in Ubuntu:
In Progress
Status in linux source package in Xenial:
Fix Committed
Bug description:
[Impact]
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
[Fix]
Cherry picked from upstream.
[Test case]
Compile, boot and basic network functionality tested using ntop.
[Potential regression]
Low. This has been in multiple trees for a while now.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2017013/+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
[Kernel-packages] [Bug 2017013] Re: net: sched: Fix use after free in red_enqueue()
** Also affects: linux-oem (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: linux-oem (Ubuntu Xenial)
** Changed in: linux-oem (Ubuntu)
Status: New => In Progress
** Changed in: linux-oem (Ubuntu)
Importance: Undecided => High
** Changed in: linux-oem (Ubuntu)
Assignee: (unassigned) => Cengiz Can (cengizcan)
** Package changed: linux-oem (Ubuntu) => linux-oem-5.17 (Ubuntu)
** Also affects: linux-oem-5.14 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-oem-5.14 (Ubuntu)
Status: New => In Progress
** Changed in: linux-oem-5.14 (Ubuntu)
Importance: Undecided => High
** Changed in: linux-oem-5.14 (Ubuntu)
Assignee: (unassigned) => Cengiz Can (cengizcan)
--
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/2017013
Title:
net: sched: Fix use after free in red_enqueue()
Status in linux package in Ubuntu:
Incomplete
Status in linux-oem-5.14 package in Ubuntu:
In Progress
Status in linux-oem-5.17 package in Ubuntu:
In Progress
Status in linux source package in Xenial:
In Progress
Bug description:
[Impact]
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
[Fix]
Cherry picked from upstream.
[Test case]
Compile, boot and basic network functionality tested using ntop.
[Potential regression]
Low. This has been in multiple trees for a while now.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2017013/+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
[Kernel-packages] [Bug 2017013] Re: net: sched: Fix use after free in red_enqueue()
** Description changed:
+ [Impact]
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
+
+ [Fix]
+ Cherry picked from upstream.
+
+ [Test case]
+ Compile, boot and basic network functionality tested using ntop.
+
+ [Potential regression]
+ Low. This has been in multiple trees for a while now.
--
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/2017013
Title:
net: sched: Fix use after free in red_enqueue()
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Xenial:
In Progress
Bug description:
[Impact]
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
[Fix]
Cherry picked from upstream.
[Test case]
Compile, boot and basic network functionality tested using ntop.
[Potential regression]
Low. This has been in multiple trees for a while now.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2017013/+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
[Kernel-packages] [Bug 2017013] Re: net: sched: Fix use after free in red_enqueue()
** Changed in: linux (Ubuntu)
Assignee: Cengiz Can (cengizcan) => (unassigned)
** CVE removed: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-3586
--
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/2017013
Title:
net: sched: Fix use after free in red_enqueue()
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Xenial:
In Progress
Bug description:
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2017013/+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
[Kernel-packages] [Bug 2017013] [NEW] net: sched: Fix use after free in red_enqueue()
Public bug reported:
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
** Affects: linux (Ubuntu Xenial)
Importance: High
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Package changed: linux-azure (Ubuntu) => linux (Ubuntu)
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => High
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Cengiz Can (cengizcan)
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-3586
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/2017013
Title:
net: sched: Fix use after free in red_enqueue()
Status in linux package in Ubuntu:
Incomplete
Status in linux source package in Xenial:
In Progress
Bug description:
We can't use "skb" again after passing it to qdisc_enqueue(). This is
basically identical to commit 2f09707 ("sch_sfb: Also store skb
len before calling child enqueue").
Fixes: d7f4f33 ("sch_red: update backlog as well")
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2017013/+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
[Kernel-packages] [Bug 1991142] Re: UAF bug caused by rose_t0timer_expiry
This fix landed on upstream with 148ca04518070910739dfc4eeda765057856403d -- 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/1991142 Title: UAF bug caused by rose_t0timer_expiry Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Jammy: In Progress Status in linux source package in Kinetic: In Progress Bug description: There are UAF bugs in rose_heartbeat_expiry(), rose_timer_expiry() and rose_idletimer_expiry(). The root cause is that del_timer() could not stop the timer handler that is running and the refcount of sock is not managed properly. One of the UAF bugs is shown below: (thread 1) |(thread 2) | rose_bind | rose_connect |rose_start_heartbeat rose_release|(wait a time) case ROSE_STATE_0 | rose_destroy_socket | rose_heartbeat_expiry rose_stop_heartbeat | sock_put(sk)|... sock_put(sk) // FREE | |bh_lock_sock(sk) // USE The sock is deallocated by sock_put() in rose_release() and then used by bh_lock_sock() in rose_heartbeat_expiry(). Although rose_destroy_socket() calls rose_stop_heartbeat(), it could not stop the timer that is running. The KASAN report triggered by POC is shown below: BUG: KASAN: use-after-free in _raw_spin_lock+0x5a/0x110 Write of size 4 at addr 88800ae59098 by task swapper/3/0 ... Call Trace: dump_stack_lvl+0xbf/0xee print_address_description+0x7b/0x440 print_report+0x101/0x230 ? irq_work_single+0xbb/0x140 ? _raw_spin_lock+0x5a/0x110 kasan_report+0xed/0x120 ? _raw_spin_lock+0x5a/0x110 kasan_check_range+0x2bd/0x2e0 _raw_spin_lock+0x5a/0x110 rose_heartbeat_expiry+0x39/0x370 ? rose_start_heartbeat+0xb0/0xb0 call_timer_fn+0x2d/0x1c0 ? rose_start_heartbeat+0xb0/0xb0 expire_timers+0x1f3/0x320 __run_timers+0x3ff/0x4d0 run_timer_softirq+0x41/0x80 __do_softirq+0x233/0x544 irq_exit_rcu+0x41/0xa0 sysvec_apic_timer_interrupt+0x8c/0xb0 asm_sysvec_apic_timer_interrupt+0x1b/0x20 RIP: 0010:default_idle+0xb/0x10 RSP: 0018:c912fea0 EFLAGS: 0202 RAX: bcae RBX: 888006660f00 RCX: bcae RDX: 0001 RSI: 843a11c0 RDI: 843a1180 RBP: dc00 R08: dc00 R09: ed100da36d46 R10: dfffe9100da36d47 R11: 83cf0950 R12: R13: 111000ccc1e0 R14: 8542af28 R15: dc00 ... Allocated by task 146: __kasan_kmalloc+0xc4/0xf0 sk_prot_alloc+0xdd/0x1a0 sk_alloc+0x2d/0x4e0 rose_create+0x7b/0x330 __sock_create+0x2dd/0x640 __sys_socket+0xc7/0x270 __x64_sys_socket+0x71/0x80 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 152: kasan_set_track+0x4c/0x70 kasan_set_free_info+0x1f/0x40 kasan_slab_free+0x124/0x190 kfree+0xd3/0x270 __sk_destruct+0x314/0x460 rose_release+0x2fa/0x3b0 sock_close+0xcb/0x230 __fput+0x2d9/0x650 task_work_run+0xd6/0x160 exit_to_user_mode_loop+0xc7/0xd0 exit_to_user_mode_prepare+0x4e/0x80 syscall_exit_to_user_mode+0x20/0x40 do_syscall_64+0x4f/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1991142/+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
[Kernel-packages] [Bug 1991142] [NEW] UAF bug caused by rose_t0timer_expiry
Public bug reported:
There are UAF bugs in rose_heartbeat_expiry(), rose_timer_expiry()
and rose_idletimer_expiry(). The root cause is that del_timer()
could not stop the timer handler that is running and the refcount
of sock is not managed properly.
One of the UAF bugs is shown below:
(thread 1) |(thread 2)
| rose_bind
| rose_connect
|rose_start_heartbeat
rose_release|(wait a time)
case ROSE_STATE_0 |
rose_destroy_socket | rose_heartbeat_expiry
rose_stop_heartbeat |
sock_put(sk)|...
sock_put(sk) // FREE |
|bh_lock_sock(sk) // USE
The sock is deallocated by sock_put() in rose_release() and
then used by bh_lock_sock() in rose_heartbeat_expiry().
Although rose_destroy_socket() calls rose_stop_heartbeat(),
it could not stop the timer that is running.
The KASAN report triggered by POC is shown below:
BUG: KASAN: use-after-free in _raw_spin_lock+0x5a/0x110
Write of size 4 at addr 88800ae59098 by task swapper/3/0
...
Call Trace:
dump_stack_lvl+0xbf/0xee
print_address_description+0x7b/0x440
print_report+0x101/0x230
? irq_work_single+0xbb/0x140
? _raw_spin_lock+0x5a/0x110
kasan_report+0xed/0x120
? _raw_spin_lock+0x5a/0x110
kasan_check_range+0x2bd/0x2e0
_raw_spin_lock+0x5a/0x110
rose_heartbeat_expiry+0x39/0x370
? rose_start_heartbeat+0xb0/0xb0
call_timer_fn+0x2d/0x1c0
? rose_start_heartbeat+0xb0/0xb0
expire_timers+0x1f3/0x320
__run_timers+0x3ff/0x4d0
run_timer_softirq+0x41/0x80
__do_softirq+0x233/0x544
irq_exit_rcu+0x41/0xa0
sysvec_apic_timer_interrupt+0x8c/0xb0
asm_sysvec_apic_timer_interrupt+0x1b/0x20
RIP: 0010:default_idle+0xb/0x10
RSP: 0018:c912fea0 EFLAGS: 0202
RAX: bcae RBX: 888006660f00 RCX: bcae
RDX: 0001 RSI: 843a11c0 RDI: 843a1180
RBP: dc00 R08: dc00 R09: ed100da36d46
R10: dfffe9100da36d47 R11: 83cf0950 R12:
R13: 111000ccc1e0 R14: 8542af28 R15: dc00
...
Allocated by task 146:
__kasan_kmalloc+0xc4/0xf0
sk_prot_alloc+0xdd/0x1a0
sk_alloc+0x2d/0x4e0
rose_create+0x7b/0x330
__sock_create+0x2dd/0x640
__sys_socket+0xc7/0x270
__x64_sys_socket+0x71/0x80
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Freed by task 152:
kasan_set_track+0x4c/0x70
kasan_set_free_info+0x1f/0x40
kasan_slab_free+0x124/0x190
kfree+0xd3/0x270
__sk_destruct+0x314/0x460
rose_release+0x2fa/0x3b0
sock_close+0xcb/0x230
__fput+0x2d9/0x650
task_work_run+0xd6/0x160
exit_to_user_mode_loop+0xc7/0xd0
exit_to_user_mode_prepare+0x4e/0x80
syscall_exit_to_user_mode+0x20/0x40
do_syscall_64+0x4f/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
** Affects: linux (Ubuntu)
Importance: High
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Affects: linux (Ubuntu Xenial)
Importance: High
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Affects: linux (Ubuntu Bionic)
Importance: High
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Affects: linux (Ubuntu Focal)
Importance: High
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Affects: linux (Ubuntu Jammy)
Importance: High
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Affects: linux (Ubuntu Kinetic)
Importance: High
Assignee: Cengiz Can (cengizcan)
Status: In Progress
** Also affects: linux (Ubuntu Kinetic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => High
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => High
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => High
** Changed in: linux (Ubuntu Jammy)
Importance: Undecided => High
** Changed in: linux (Ubuntu Kinetic)
Importance: Undecided => High
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Bionic)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
** Changed in: linux (Ubuntu Jammy)
Status: New => In Progress
** Changed in: linux (Ubuntu Kinetic)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Cengiz Can (cengizcan)
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Cengiz Can (cengizcan)
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) =
[Kernel-packages] [Bug 1990690] Re: Users belonging to video group may trigger a deadlock WARN
** Description changed:
[Impact]
- One of the fixing commits for CVE-2021-33655, commit 159a96b199b4
+ 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.
+ 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:
- (_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
-
+ (_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
+
but task is already holding lock:
- (_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
-
+ (_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
+
other info that might help us debug this:
- Possible unsafe locking scenario:
- CPU0
-
-lock(_info->lock);
-lock(_info->lock);
-
+ Possible unsafe locking scenario:
+ CPU0
+
+ lock(_info->lock);
+ lock(_info->lock);
+
*** DEADLOCK ***
- May be due to missing lock nesting notation
- 2 locks held by refresh/1248:
- #0: (console_lock){+.+.}, at: [<8000aa2b>] do_fb_ioctl+0x435/0x5e0
- #1: (_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
-
+ May be due to missing lock nesting notation
+ 2 locks held by refresh/1248:
+ #0: (console_lock){+.+.}, at: [<8000aa2b>] do_fb_ioctl+0x435/0x5e0
+ #1: (_info->lock){+.+.}, at: [<4c154cfe>] 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:7ffe2a930b48 EFLAGS: 0213 ORIG_RAX: 0010
- RAX: ffda RBX: RCX: 7f22acca7217
- RDX: 7ffe2a930c30 RSI: 4601 RDI: 0003
- RBP: 7ffe2a930d40 R08: R09:
- R10: R11: 0213 R12: 5624ac8fc7c0
- R13: 7ffe2a930e20 R14: R15:
+ 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:7ffe2a930b48 EFLAGS: 0213 ORIG_RAX: 0010
+ RAX: ffda RBX: RCX: 7f22acca7217
+ RDX: 7ffe2a930c30 RSI: 4601 RDI: 0003
+ RBP: 7ffe2a930d40 R08: R09:
+ R10: R11: 0213 R12: 5624ac8fc7c0
+ R13: 7ffe2a930e20 R14: R15:
[Test case]
- Run a sample framebuffer userspace test to call FBIOPUT_VSCREENINFO
+ Run a sample framebuffer userspace test to call FBIOPUT_VSCREENINFO
and verified with LOCKDEP.
[Potential regressions]
There are no new potential regressions.
--
You received this bug notification because you are a member of Kernel
Packages, which is
[Kernel-packages] [Bug 1990690] Re: Users belonging to video group may trigger a deadlock WARN
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Cengiz Can (cengizcan)
** Changed in: linux (Ubuntu)
Assignee: Cengiz Can (cengizcan) => (unassigned)
--
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:
(_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
but task is already holding lock:
(_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_info->lock);
lock(_info->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by refresh/1248:
#0: (console_lock){+.+.}, at: [<8000aa2b>] do_fb_ioctl+0x435/0x5e0
#1: (_info->lock){+.+.}, at: [<4c154cfe>] 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:7ffe2a930b48 EFLAGS: 0213 ORIG_RAX: 0010
RAX: ffda RBX: RCX: 7f22acca7217
RDX: 7ffe2a930c30 RSI: 4601 RDI: 0003
RBP: 7ffe2a930d40 R08: R09:
R10: R11: 0213 R12: 5624ac8fc7c0
R13: 7ffe2a930e20 R14: R15:
[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
[Kernel-packages] [Bug 1990690] [NEW] Users belonging to video group may trigger a deadlock WARN
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:
(_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
but task is already holding lock:
(_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_info->lock);
lock(_info->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by refresh/1248:
#0: (console_lock){+.+.}, at: [<8000aa2b>] do_fb_ioctl+0x435/0x5e0
#1: (_info->lock){+.+.}, at: [<4c154cfe>] 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:7ffe2a930b48 EFLAGS: 0213 ORIG_RAX: 0010
RAX: ffda RBX: RCX: 7f22acca7217
RDX: 7ffe2a930c30 RSI: 4601 RDI: 0003
RBP: 7ffe2a930d40 R08: R09:
R10: R11: 0213 R12: 5624ac8fc7c0
R13: 7ffe2a930e20 R14: R15:
[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:
(_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
but task is already holding lock:
(_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_info->lock);
lock(_info->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by refresh/1248:
#0: (console_lock){+.+.}, at: [<8000aa2b>] do_fb_ioctl+0x435/0x5e0
#1: (_info->lock){+.+.}, at: [<4c154cfe>] lock_fb_info+0x1d/0x40
stack backtrace:
CPU: 0 PID: 1248 Comm:
[Kernel-packages] [Bug 1975804] Re: [SRU][OEM-5.14/OEM-5.17/J][PATCH 0/2] Fix system hangs after s2idle on AMD A+A GPU
** Description changed:
[Impact]
- Sytesm may hang after s2idle on AMD A+A GPU config due to the following
+ System may hang after s2idle on AMD A+A GPU config due to the following
commits:
8b328c64c7082278c888927f00e526786eec2880 ("drm/amdgpu: don't use BACO
for reset in S3") https://bugs.launchpad.net/bugs/1968475
a26d80ba0d9e67ea11cbfc25618320163497d3fe ("drm/amd/pm: keep the BACO
feature enabled for suspend") https://bugs.launchpad.net/bugs/1958371
[Fix]
Revert one commit and don't reset dGPU when s2idle
[Test]
Verified on AMD RMB, stress s2idle passed.
[Where problems could occur]
Low risk, it may break s2idle on AMD platform.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-5.14 in Ubuntu.
https://bugs.launchpad.net/bugs/1975804
Title:
[SRU][OEM-5.14/OEM-5.17/J][PATCH 0/2] Fix system hangs after s2idle on
AMD A+A GPU
Status in HWE Next:
New
Status in linux package in Ubuntu:
In Progress
Status in linux-oem-5.14 package in Ubuntu:
New
Status in linux-oem-5.17 package in Ubuntu:
New
Status in linux-oem-5.14 source package in Focal:
New
Status in linux source package in Jammy:
New
Status in linux-oem-5.17 source package in Jammy:
New
Bug description:
[Impact]
System may hang after s2idle on AMD A+A GPU config due to the following
commits:
8b328c64c7082278c888927f00e526786eec2880 ("drm/amdgpu: don't use BACO
for reset in S3") https://bugs.launchpad.net/bugs/1968475
a26d80ba0d9e67ea11cbfc25618320163497d3fe ("drm/amd/pm: keep the BACO
feature enabled for suspend") https://bugs.launchpad.net/bugs/1958371
[Fix]
Revert one commit and don't reset dGPU when s2idle
[Test]
Verified on AMD RMB, stress s2idle passed.
[Where problems could occur]
Low risk, it may break s2idle on AMD platform.
To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1975804/+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
