Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
b5cb8bd4f36cb1ef37d1d34dada - https://git.kernel.org/stable/c/1489824e5226a26841c70639ebd2d1aed390764b - https://git.kernel.org/stable/c/d1f9f79fa2af8e3b45cffdeef66e05833480148a
CVE ID: CVE-2025-21807 State: PUBLISHED Published: 2025-02-27T20:00:59.560Z Last Updated: 2025-05-04T07:21:37.603Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: fix queue freeze vs limits lock order in sysfs store methods queue_attr_store() always freezes a device queue before calling the attribute store operation. For attributes that control queue limits, the store operation will also lock the queue limits with a call to queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may need to issue commands to a device to obtain limit values from the hardware with the queue limits locked. This creates a potential
ue commands to a device to obtain limit values from the hardware with the queue limits locked. This creates a potential ABBA deadlock situation if a user attempts to modify a limit (thus freezing the device queue) while the device driver starts a revalidation of the device queue limits. Avoid such deadlock by not freezing the queue before calling the ->store_limit() method in struct queue_sysfs_entry and instead use the queue_limits_commit_update_frozen helper to freeze the queue after taking the limits lock. This also removes taking the sysfs lock for the store_limit method as it doesn't protect anything here, but creates even more nesting. Hopefully it will go away from the actual sysfs me
d as it doesn't protect anything here, but creates even more nesting. Hopefully it will go away from the actual sysfs methods entirely soon. (commit log adapted from a similar patch from Damien Le Moal) References: - https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b - https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec
CVE ID: CVE-2025-21808 State: PUBLISHED Published: 2025-02-27T20:01:00.328Z Last Updated: 2025-05-04T07:21:38.647Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: xdp: Disallow attaching device-bound programs in generic mode Device-bound programs are used to support RX metadata kfuncs. These kfuncs are driver-specific and rely on the driver context to read the metadata. This means they can't work in generic XDP mode. However, there is no check to disallow such programs from being attached in generic mode, in which case the metadata kfuncs will be called in an invalid context, leading to crashes. Fix this by adding a check t
in which case the metadata kfuncs will be called in an invalid context, leading to crashes. Fix this by adding a check to disallow attaching device-bound programs in generic mode. References: - https://git.kernel.org/stable/c/b1bc4a35a04cbeb85b6ef5911ec015baa424989f - https://git.kernel.org/stable/c/557707906dd3e34b8a8c265f664d19f95799937e - https://git.kernel.org/stable/c/5a9eae683d6c36e8a7aa31e5eb8b369e41aa66e1 - https://git.kernel.org/stable/c/3595599fa8360bb3c7afa7ee50c810b4a64106ea
CVE ID: CVE-2025-21809 State: PUBLISHED Published: 2025-02-27T20:01:00.969Z Last Updated: 2025-10-01T19:36:38.646Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rxrpc, afs: Fix peer hash locking vs RCU callback In its address list, afs now retains pointers to and refs on one or more rxrpc_peer objects. The address list is freed under RCU and at this time, it puts the refs on those peers. Now, when an rxrpc_peer object runs out of refs, it gets removed from the peer hash table and, for that, rxrpc has to take a spinlock. However, it is now being called from afs's RCU cleanup, which takes place in BH context - but it is just tak
a spinlock. However, it is now being called from afs's RCU cleanup, which takes place in BH context - but it is just taking an ordinary spinlock. The put may also be called from non-BH context, and so there exists the possibility of deadlock if the BH-based RCU cleanup happens whilst the hash spinlock is held. This led to the attached lockdep complaint. Fix this by changing spinlocks of rxnet->peer_hash_lock back to BH-disabling locks. ================================ WARNING: inconsistent lock state 6.13.0-rc5-build2+ #1223 Tainted: G E -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff88810babe228 (&rxnet->p
onsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff88810babe228 (&rxnet->peer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180 {SOFTIRQ-ON-W} state was registered at: mark_usage+0x164/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_peer_keepalive_worker+0x144/0x440 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x19b/0x1b0 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 irq event stamp: 972402 hardirqs last enabled at (972402): [<ffffffff8244360e>] _raw_spin_unlock_irqrestore+0x2e/0x50 hardirqs last disabled at (972401): [<ffffffff82443328>]
02): [<ffffffff8244360e>] _raw_spin_unlock_irqrestore+0x2e/0x50 hardirqs last disabled at (972401): [<ffffffff82443328>] _raw_spin_lock_irqsave+0x18/0x60 softirqs last enabled at (972300): [<ffffffff810ffbbe>] handle_softirqs+0x3ee/0x430 softirqs last disabled at (972313): [<ffffffff810ffc54>] __irq_exit_rcu+0x44/0x110 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rxnet->peer_hash_lock); <Interrupt> lock(&rxnet->peer_hash_lock); *** DEADLOCK *** 1 lock held by swapper/1/0: #0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30 stack backtrace: CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223 Taint
_lock_acquire+0x7/0x30 stack backtrace: CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223 Tainted: [E]=UNSIGNED_MODULE Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <IRQ> dump_stack_lvl+0x57/0x80 print_usage_bug.part.0+0x227/0x240 valid_state+0x53/0x70 mark_lock_irq+0xa5/0x2f0 mark_lock+0xf7/0x170 mark_usage+0xe1/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_put_peer+0xcb/0x180 afs_free_addrlist+0x46/0x90 [kafs] rcu_do_batch+0x2d2/0x640 rcu_core+0x2f7/0x350 handle_softirqs+0x1ee/0x430 __irq_exit_rcu+0x44/0x110 irq_exit_rcu+0xa/0x30 sysvec_apic_timer_interrupt+0x7f/0xa0 </IRQ> Additional Ana
+0x1ee/0x430 __irq_exit_rcu+0x44/0x110 irq_exit_rcu+0xa/0x30 sysvec_apic_timer_interrupt+0x7f/0xa0 </IRQ> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/10ba5a3d57af20e494e0d979d1894260989235dd - https://git.kernel.org/stable/c/0e77dd41689637ac4e1b8fe0f27541f373640855 - https://git.kernel.org/stable/c/79d458c13056559d49b5e41fbc4b6890e68cf65b
CVE ID: CVE-2025-21810 State: PUBLISHED Published: 2025-02-27T20:01:01.630Z Last Updated: 2025-05-04T07:21:40.730Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: driver core: class: Fix wild pointer dereferences in API class_dev_iter_next() There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage: // All members of @iter are wild pointers. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter
lass for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...); // Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... }; // Also dereference these wild pointers here. class_dev_iter_exit(&iter); Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error.
itialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next(). References: - https://git.kernel.org/stable/c/f4b9bc823b0cfdebfed479c0e87d6939c7562e87 - https://git.kernel.org/stable/c/1614e75d1a1b63db6421c7a4bf37004720c7376c - https://git.kernel.org/stable/c/5c504e9767b947cf7d4e29b811c0c8b3c53242b7 - https://git.kernel.org/stable/c/e128f82f7006991c99a58114f70ef61e937b1ac1
CVE ID: CVE-2025-21811 State: PUBLISHED Published: 2025-02-27T20:01:02.256Z Last Updated: 2025-11-03T20:59:47.268Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection
ilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e1fc4a90a90ea8514246c45435662531975937d9 - https://git.kernel.org/stable/c/72cf688d0ce7e642b12ddc9b2a42524737ec1b4a - https://git.kernel.org/stable/c/d8ff250e085a4c4cdda4ad1cdd234ed110393143 - https://git.kernel.org/stable/c/58c27fa7a610b6e8d44e6220e7dbddfbaccaf439
le/c/d8ff250e085a4c4cdda4ad1cdd234ed110393143 - https://git.kernel.org/stable/c/58c27fa7a610b6e8d44e6220e7dbddfbaccaf439 - https://git.kernel.org/stable/c/8e1b9201c9a24638cf09c6e1c9f224157328010b - https://git.kernel.org/stable/c/4b08d23d7d1917bef4fbee8ad81372f49b006656 - https://git.kernel.org/stable/c/c437dfac9f7a5a46ac2a5e6d6acd3059e9f68188 - https://git.kernel.org/stable/c/367a9bffabe08c04f6d725032cce3d891b2b9e1a
CVE ID: CVE-2025-21812 State: PUBLISHED Published: 2025-02-27T20:01:02.837Z Last Updated: 2025-11-03T20:59:48.635Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net
z.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inl
48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/commo
f5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_sets
tex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock
lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a
241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2802ed4ced27ebd474828fc67ffd7d66f11e3605 - https://git.kernel.org/stable/c/7705d8a7f2c26c80973c81093db07c6022b2b30e - https://git.kernel.org/stable/c/8937f5e38a218531dce2a89fae60e3adcc2311e1 - https://git.kernel.org/stable/c/c2531db6de3c95551be58878f859c6a053b7eb2e - https://git.kernel.org/stable/c/95fc45d1dea8e1253f8ec58abc
ernel.org/stable/c/c2531db6de3c95551be58878f859c6a053b7eb2e - https://git.kernel.org/stable/c/95fc45d1dea8e1253f8ec58abc5befb71553d666
CVE ID: CVE-2025-21813 State: PUBLISHED Published: 2025-02-27T20:04:13.433Z Last Updated: 2025-05-04T07:21:43.981Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: timers/migration: Fix off-by-one root mis-connection Before attaching a new root to the old root, the children counter of the new root is checked to verify that only the upcoming CPU's top group have been connected to it. However since the recently added commit b729cc1ec21a ("timers/migration: Fix another race between hotplug and idle entry/exit") this check is not valid anymore because the old root is pre-accounted as a child to the new root. Therefore after connectin
s check is not valid anymore because the old root is pre-accounted as a child to the new root. Therefore after connecting the upcoming CPU's top group to the new root, the children count to be expected must be 2 and not 1 anymore. This omission results in the old root to not be connected to the new root. Then eventually the system may run with more than one top level, which defeats the purpose of a single idle migrator. Also the old root is pre-accounted but not connected upon the new root creation. But it can be connected to the new root later on. Therefore the old root may be accounted twice to the new root. The propagation of such overcommit can end up creating a double final top-level ro
y be accounted twice to the new root. The propagation of such overcommit can end up creating a double final top-level root with a groupmask incorrectly initialized. Although harmless given that the final top level roots will never have a parent to walk up to, this oddity opportunistically reported the core issue: WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: <IRQ> ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt </IRQ> Fix the problem by taking the
odic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt </IRQ> Fix the problem by taking the old root into account in the children count of the new root so the connection is not omitted. Also warn when more than one top level group exists to better detect similar issues in the future. References: - https://git.kernel.org/stable/c/c6dd70e5b465a2b77c7a7c3d868736d302e29aec - https://git.kernel.org/stable/c/6f449d8fa1808a7f9ee644866bbc079285dbefdd - https://git.kernel.org/stable/c/868c9037df626b3c245ee26a290a03ae1f9f58d3
CVE ID: CVE-2025-21814 State: PUBLISHED Published: 2025-02-27T20:04:14.089Z Last Updated: 2025-11-03T20:59:50.380Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fdc1e72487781dd7705bcbe30878bee7d5d1f3e8 -
otes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fdc1e72487781dd7705bcbe30878bee7d5d1f3e8 - https://git.kernel.org/stable/c/9df3a9284f39bfd51a9f72a6a165c79e2aa5066b - https://git.kernel.org/stable/c/1334c64a5d1de6666e0c9f984db6745083df1eb4 - https://git.kernel.org/stable/c/5d1041c76de656f9f8d5a192218039a9acf9bd00 - https://git.kernel.org/stable/c/81846070cba17125a866e8023c01d3465b153339 - https://git.kernel.org/stable/c/8441aea46445252df5d2eed6deb6d5246fc24002 - https://git.kernel.org/stable/c/755caf4ee1c615ee5717862e427124370f46b1f3 - https://git.kernel.org/stable/c/fd53aa40e65f518453115b6f56183b0c201db26b
CVE ID: CVE-2025-21815 State: PUBLISHED Published: 2025-02-27T20:04:14.733Z Last Updated: 2025-05-04T07:21:46.285Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/compaction: fix UBSAN shift-out-of-bounds warning syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL << order) in isolate_freepages_block(). The bogus compound_order can be any value because it is union with flags. Add back the MAX_PAGE_ORDER check to fix the warning. References: - https://git.kernel.org/stable/c/4491159774d973a9e2e998d25d8fbb20fada6dfa - https://git.kernel.org/stable/c/10b7d3eb535098ccd4c82a182a33655d8a0e5c88 - https://git.kernel.org/st
25d8fbb20fada6dfa - https://git.kernel.org/stable/c/10b7d3eb535098ccd4c82a182a33655d8a0e5c88 - https://git.kernel.org/stable/c/d1366e74342e75555af2648a2964deb2d5c92200
CVE ID: CVE-2025-21816 State: PUBLISHED Published: 2025-02-27T20:04:15.356Z Last Updated: 2025-11-03T17:32:08.230Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING hrtimers are migrated away from the dying CPU to any online target at the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress. However wakeups can still be performed by the outgoing CPU after CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal bal
HRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored. The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds: _ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq) The
Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq) The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end of its work through cpu_stop_signal_done() and performs a wake up that eventually arms the deadline server timer: WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: <TASK> start_dl_timer enqueue_dl_entity dl_server_start
66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Call Trace: <TASK> start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU. This will also allow to revert all the above RCU disgraceful hacks. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/82ac6adbbb2aad14548a71d5e2e37f4964a15e38 - https://git.kernel.org/stable/c/63815bef47ec25f5a125019ca480882481ee1
table/c/82ac6adbbb2aad14548a71d5e2e37f4964a15e38 - https://git.kernel.org/stable/c/63815bef47ec25f5a125019ca480882481ee1553 - https://git.kernel.org/stable/c/e456a88bddae4030ba962447bb84be6669f2a0c1 - https://git.kernel.org/stable/c/2aecec58e9040ce3d2694707889f9914a2374955 - https://git.kernel.org/stable/c/53dac345395c0d2493cbc2f4c85fe38aef5b63f5