Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0)<br /> <br /> If an mremap() syscall with old_size=0 ends up in move_page_tables(), it<br /> will call invalidate_range_start()/invalidate_range_end() unnecessarily,<br /> i.e. with an empty range.<br /> <br /> This causes a WARN in KVM&amp;#39;s mmu_notifier. In the past, empty ranges<br /> have been diagnosed to be off-by-one bugs, hence the WARNing. Given the<br /> low (so far) number of unique reports, the benefits of detecting more<br /> buggy callers seem to outweigh the cost of having to fix cases such as<br /> this one, where userspace is doing something silly. In this particular<br /> case, an early return from move_page_tables() is enough to fix the<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone<br /> <br /> btrfs_can_activate_zone() can be called with the device_list_mutex already<br /> held, which will lead to a deadlock:<br /> <br /> insert_dev_extents() // Takes device_list_mutex<br /> `-&gt; insert_dev_extent()<br /> `-&gt; btrfs_insert_empty_item()<br /> `-&gt; btrfs_insert_empty_items()<br /> `-&gt; btrfs_search_slot()<br /> `-&gt; btrfs_cow_block()<br /> `-&gt; __btrfs_cow_block()<br /> `-&gt; btrfs_alloc_tree_block()<br /> `-&gt; btrfs_reserve_extent()<br /> `-&gt; find_free_extent()<br /> `-&gt; find_free_extent_update_loop()<br /> `-&gt; can_allocate_chunk()<br /> `-&gt; btrfs_can_activate_zone() // Takes device_list_mutex again<br /> <br /> Instead of using the RCU on fs_devices-&gt;device_list we<br /> can use fs_devices-&gt;alloc_list, protected by the chunk_mutex to traverse<br /> the list of active devices.<br /> <br /> We are in the chunk allocation thread. The newer chunk allocation<br /> happens from the devices in the fs_device-&gt;alloc_list protected by the<br /> chunk_mutex.<br /> <br /> btrfs_create_chunk()<br /> lockdep_assert_held(&amp;info-&gt;chunk_mutex);<br /> gather_device_info<br /> list_for_each_entry(device, &amp;fs_devices-&gt;alloc_list, dev_alloc_list)<br /> <br /> Also, a device that reappears after the mount won&amp;#39;t join the alloc_list<br /> yet and, it will be in the dev_list, which we don&amp;#39;t want to consider in<br /> the context of the chunk alloc.<br /> <br /> [15.166572] WARNING: possible recursive locking detected<br /> [15.167117] 5.17.0-rc6-dennis #79 Not tainted<br /> [15.167487] --------------------------------------------<br /> [15.167733] kworker/u8:3/146 is trying to acquire lock:<br /> [15.167733] ffff888102962ee0 (&amp;fs_devs-&gt;device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.167733]<br /> [15.167733] but task is already holding lock:<br /> [15.167733] ffff888102962ee0 (&amp;fs_devs-&gt;device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]<br /> [15.167733]<br /> [15.167733] other info that might help us debug this:<br /> [15.167733] Possible unsafe locking scenario:<br /> [15.167733]<br /> [15.171834] CPU0<br /> [15.171834] ----<br /> [15.171834] lock(&amp;fs_devs-&gt;device_list_mutex);<br /> [15.171834] lock(&amp;fs_devs-&gt;device_list_mutex);<br /> [15.171834]<br /> [15.171834] *** DEADLOCK ***<br /> [15.171834]<br /> [15.171834] May be due to missing lock nesting notation<br /> [15.171834]<br /> [15.171834] 5 locks held by kworker/u8:3/146:<br /> [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0<br /> [15.171834] #1: ffffc9000067be80 ((work_completion)(&amp;fs_info-&gt;async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0<br /> [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs]<br /> [15.176244] #3: ffff888102962ee0 (&amp;fs_devs-&gt;device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]<br /> [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs]<br /> [15.179641]<br /> [15.179641] stack backtrace:<br /> [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79<br /> [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014<br /> [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]<br /> [15.179641] Call Trace:<br /> [15.179641] <br /> [15.179641] dump_stack_lvl+0x45/0x59<br /> [15.179641] __lock_acquire.cold+0x217/0x2b2<br /> [15.179641] lock_acquire+0xbf/0x2b0<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] __mutex_lock+0x8e/0x970<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] ? lock_is_held_type+0xd7/0x130<br /> [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] find_free_extent+0x15a/0x14f0 [btrfs]<br /> [15.183838] ? _raw_spin_unlock+0x24/0x40<br /> [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs]<br /> [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs]<br /> [15.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempolicy: fix mpol_new leak in shared_policy_replace<br /> <br /> If mpol_new is allocated but not used in restart loop, mpol_new will be<br /> freed via mpol_put before returning to the caller. But refcnt is not<br /> initialized yet, so mpol_put could not do the right things and might<br /> leak the unused mpol_new. This would happen if mempolicy was updated on<br /> the shared shmem file while the sp-&gt;lock has been dropped during the<br /> memory allocation.<br /> <br /> This issue could be triggered easily with the below code snippet if<br /> there are many processes doing the below work at the same time:<br /> <br /> shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);<br /> shm = shmat(shmid, 0, 0);<br /> loop many times {<br /> mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);<br /> mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,<br /> maxnode, 0);<br /> }

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> highmem: fix checks in __kmap_local_sched_{in,out}<br /> <br /> When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check<br /> that even slots in the tsk-&gt;kmap_ctrl.pteval are unmapped. The slots are<br /> initialized with 0 value, but the check is done with pte_none. 0 pte<br /> however does not necessarily mean that pte_none will return true. e.g.<br /> on xtensa it returns false, resulting in the following runtime warnings:<br /> <br /> WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108<br /> CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13<br /> Call Trace:<br /> dump_stack+0xc/0x40<br /> __warn+0x8f/0x174<br /> warn_slowpath_fmt+0x48/0xac<br /> __kmap_local_sched_out+0x51/0x108<br /> __schedule+0x71a/0x9c4<br /> preempt_schedule_irq+0xa0/0xe0<br /> common_exception_return+0x5c/0x93<br /> do_wp_page+0x30e/0x330<br /> handle_mm_fault+0xa70/0xc3c<br /> do_page_fault+0x1d8/0x3c4<br /> common_exception+0x7f/0x7f<br /> <br /> WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0<br /> CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13<br /> Call Trace:<br /> dump_stack+0xc/0x40<br /> __warn+0x8f/0x174<br /> warn_slowpath_fmt+0x48/0xac<br /> __kmap_local_sched_in+0x50/0xe0<br /> finish_task_switch$isra$0+0x1ce/0x2f8<br /> __schedule+0x86e/0x9c4<br /> preempt_schedule_irq+0xa0/0xe0<br /> common_exception_return+0x5c/0x93<br /> do_wp_page+0x30e/0x330<br /> handle_mm_fault+0xa70/0xc3c<br /> do_page_fault+0x1d8/0x3c4<br /> common_exception+0x7f/0x7f<br /> <br /> Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove()<br /> <br /> The function mpt3sas_transport_port_remove() called in<br /> _scsih_expander_node_remove() frees the port field of the sas_expander<br /> structure, leading to the following use-after-free splat from KASAN when<br /> the ioc_info() call following that function is executed (e.g. when doing<br /> rmmod of the driver module):<br /> <br /> [ 3479.371167] ==================================================================<br /> [ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531<br /> [ 3479.393524]<br /> [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436<br /> [ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021<br /> [ 3479.409263] Call Trace:<br /> [ 3479.411743] <br /> [ 3479.413875] dump_stack_lvl+0x45/0x59<br /> [ 3479.417582] print_address_description.constprop.0+0x1f/0x120<br /> [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.429469] kasan_report.cold+0x83/0xdf<br /> [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas]<br /> [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40<br /> [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas]<br /> [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas]<br /> [ 3479.465529] ? down_write+0xde/0x150<br /> [ 3479.470746] ? up_write+0x14d/0x460<br /> [ 3479.475840] ? kernfs_find_ns+0x137/0x310<br /> [ 3479.481438] pci_device_remove+0x65/0x110<br /> [ 3479.487013] __device_release_driver+0x316/0x680<br /> [ 3479.493180] driver_detach+0x1ec/0x2d0<br /> [ 3479.498499] bus_remove_driver+0xe7/0x2d0<br /> [ 3479.504081] pci_unregister_driver+0x26/0x250<br /> [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas]<br /> [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510<br /> [ 3479.522315] ? free_module+0xaa0/0xaa0<br /> [ 3479.527593] ? __cond_resched+0x1c/0x90<br /> [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70<br /> [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110<br /> [ 3479.551828] do_syscall_64+0x35/0x80<br /> [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 3479.563402] RIP: 0033:0x7f1fc482483b<br /> ...<br /> [ 3479.943087] ==================================================================<br /> <br /> Fix this by introducing the local variable port_id to store the port ID<br /> value before executing mpt3sas_transport_port_remove(). This local variable<br /> is then used in the call to ioc_info() instead of dereferencing the freed<br /> port structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/omap: Fix regression in probe for NULL pointer dereference<br /> <br /> Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started<br /> triggering a NULL pointer dereference for some omap variants:<br /> <br /> __iommu_probe_device from probe_iommu_group+0x2c/0x38<br /> probe_iommu_group from bus_for_each_dev+0x74/0xbc<br /> bus_for_each_dev from bus_iommu_probe+0x34/0x2e8<br /> bus_iommu_probe from bus_set_iommu+0x80/0xc8<br /> bus_set_iommu from omap_iommu_init+0x88/0xcc<br /> omap_iommu_init from do_one_initcall+0x44/0x24<br /> <br /> This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV)<br /> as noted by Jason Gunthorpe .<br /> <br /> Looks like the regression already happened with an earlier commit<br /> 6785eb9105e3 ("iommu/omap: Convert to probe/release_device() call-backs")<br /> that changed the function return type and missed converting one place.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qede: confirm skb is allocated before using<br /> <br /> qede_build_skb() assumes build_skb() always works and goes straight<br /> to skb_reserve(). However, build_skb() can fail under memory pressure.<br /> This results in a kernel panic because the skb to reserve is NULL.<br /> <br /> Add a check in case build_skb() failed to allocate and return NULL.<br /> <br /> The NULL return is handled correctly in callers to qede_build_skb().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: Fix five use after free bugs in get_initial_state<br /> <br /> In get_initial_state, it calls notify_initial_state_done(skb,..) if<br /> cb-&gt;args[5]==1. If genlmsg_put() failed in notify_initial_state_done(),<br /> the skb will be freed by nlmsg_free(skb).<br /> Then get_initial_state will goto out and the freed skb will be used by<br /> return value skb-&gt;len, which is a uaf bug.<br /> <br /> What&amp;#39;s worse, the same problem goes even further: skb can also be<br /> freed in the notify_*_state_change -&gt; notify_*_state calls below.<br /> Thus 4 additional uaf bugs happened.<br /> <br /> My patch lets the problem callee functions: notify_initial_state_done<br /> and notify_*_state_change return an error code if errors happen.<br /> So that the error codes could be propagated and the uaf bugs can be avoid.<br /> <br /> v2 reports a compilation warning. This v3 fixed this warning and built<br /> successfully in my local environment with no additional warnings.<br /> v2: https://lore.kernel.org/patchwork/patch/1435218/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix leak of nested actions<br /> <br /> While parsing user-provided actions, openvswitch module may dynamically<br /> allocate memory and store pointers in the internal copy of the actions.<br /> So this memory has to be freed while destroying the actions.<br /> <br /> Currently there are only two such actions: ct() and set(). However,<br /> there are many actions that can hold nested lists of actions and<br /> ovs_nla_free_flow_actions() just jumps over them leaking the memory.<br /> <br /> For example, removal of the flow with the following actions will lead<br /> to a leak of the memory allocated by nf_ct_tmpl_alloc():<br /> <br /> actions:clone(ct(commit),0)<br /> <br /> Non-freed set() action may also leak the &amp;#39;dst&amp;#39; structure for the<br /> tunnel info including device references.<br /> <br /> Under certain conditions with a high rate of flow rotation that may<br /> cause significant memory leak problem (2MB per second in reporter&amp;#39;s<br /> case). The problem is also hard to mitigate, because the user doesn&amp;#39;t<br /> have direct control over the datapath flows generated by OVS.<br /> <br /> Fix that by iterating over all the nested actions and freeing<br /> everything that needs to be freed recursively.<br /> <br /> New build time assertion should protect us from this problem if new<br /> actions will be added in the future.<br /> <br /> Unfortunately, openvswitch module doesn&amp;#39;t use NLA_F_NESTED, so all<br /> attributes has to be explicitly checked. sample() and clone() actions<br /> are mixing extra attributes into the user-provided action list. That<br /> prevents some code generalization too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lz4: fix LZ4_decompress_safe_partial read out of bound<br /> <br /> When partialDecoding, it is EOF if we&amp;#39;ve either filled the output buffer<br /> or can&amp;#39;t proceed with reading an offset for following match.<br /> <br /> In some extreme corner cases when compressed data is suitably corrupted,<br /> UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial<br /> may lead to read out of bound problem during decoding. lz4 upstream has<br /> fixed it [2] and this issue has been disscussed here [3] before.<br /> <br /> current decompression routine was ported from lz4 v1.8.3, bumping<br /> lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we&amp;#39;d<br /> better fix it first.<br /> <br /> [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/<br /> [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#<br /> [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release correct delalloc amount in direct IO write path<br /> <br /> Running generic/406 causes the following WARNING in btrfs_destroy_inode()<br /> which tells there are outstanding extents left.<br /> <br /> In btrfs_get_blocks_direct_write(), we reserve a temporary outstanding<br /> extents with btrfs_delalloc_reserve_metadata() (or indirectly from<br /> btrfs_delalloc_reserve_space(()). We then release the outstanding extents<br /> with btrfs_delalloc_release_extents(). However, the "len" can be modified<br /> in the COW case, which releases fewer outstanding extents than expected.<br /> <br /> Fix it by calling btrfs_delalloc_release_extents() for the original length.<br /> <br /> To reproduce the warning, the filesystem should be 1 GiB. It&amp;#39;s<br /> triggering a short-write, due to not being able to allocate a large<br /> extent and instead allocating a smaller one.<br /> <br /> WARNING: CPU: 0 PID: 757 at fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs]<br /> Modules linked in: btrfs blake2b_generic xor lzo_compress<br /> lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram<br /> zsmalloc<br /> CPU: 0 PID: 757 Comm: umount Not tainted 5.17.0-rc8+ #101<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014<br /> RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs]<br /> RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206<br /> RAX: 0000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000<br /> RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78<br /> RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8<br /> R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800<br /> R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68<br /> FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> destroy_inode+0x33/0x70<br /> dispose_list+0x43/0x60<br /> evict_inodes+0x161/0x1b0<br /> generic_shutdown_super+0x2d/0x110<br /> kill_anon_super+0xf/0x20<br /> btrfs_kill_super+0xd/0x20 [btrfs]<br /> deactivate_locked_super+0x27/0x90<br /> cleanup_mnt+0x12c/0x180<br /> task_work_run+0x54/0x80<br /> exit_to_user_mode_prepare+0x152/0x160<br /> syscall_exit_to_user_mode+0x12/0x30<br /> do_syscall_64+0x42/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f854a000fb7

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix by adding FPU protection for dcn30_internal_validate_bw<br /> <br /> [Why]<br /> Below general protection fault observed when WebGL Aquarium is run for<br /> longer duration. If drm debug logs are enabled and set to 0x1f then the<br /> issue is observed within 10 minutes of run.<br /> <br /> [ 100.717056] general protection fault, probably for non-canonical address 0x2d33302d32323032: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 100.727921] CPU: 3 PID: 1906 Comm: DrmThread Tainted: G W 5.15.30 #12 d726c6a2d6ebe5cf9223931cbca6892f916fe18b<br /> [ 100.754419] RIP: 0010:CalculateSwathWidth+0x1f7/0x44f<br /> [ 100.767109] Code: 00 00 00 f2 42 0f 11 04 f0 48 8b 85 88 00 00 00 f2 42 0f 10 04 f0 48 8b 85 98 00 00 00 f2 42 0f 11 04 f0 48 8b 45 10 0f 57 c0 42 0f 2a 04 b0 0f 57 c9 f3 43 0f 2a 0c b4 e8 8c e2 f3 ff 48 8b<br /> [ 100.781269] RSP: 0018:ffffa9230079eeb0 EFLAGS: 00010246<br /> [ 100.812528] RAX: 2d33302d32323032 RBX: 0000000000000500 RCX: 0000000000000000<br /> [ 100.819656] RDX: 0000000000000001 RSI: ffff99deb712c49c RDI: 0000000000000000<br /> [ 100.826781] RBP: ffffa9230079ef50 R08: ffff99deb712460c R09: ffff99deb712462c<br /> [ 100.833907] R10: ffff99deb7124940 R11: ffff99deb7124d70 R12: ffff99deb712ae44<br /> [ 100.841033] R13: 0000000000000001 R14: 0000000000000000 R15: ffffa9230079f0a0<br /> [ 100.848159] FS: 00007af121212640(0000) GS:ffff99deba780000(0000) knlGS:0000000000000000<br /> [ 100.856240] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 100.861980] CR2: 0000209000fe1000 CR3: 000000011b18c000 CR4: 0000000000350ee0<br /> [ 100.869106] Call Trace:<br /> [ 100.871555] <br /> [ 100.873655] ? asm_sysvec_reschedule_ipi+0x12/0x20<br /> [ 100.878449] CalculateSwathAndDETConfiguration+0x1a3/0x6dd<br /> [ 100.883937] dml31_ModeSupportAndSystemConfigurationFull+0x2ce4/0x76da<br /> [ 100.890467] ? kallsyms_lookup_buildid+0xc8/0x163<br /> [ 100.895173] ? kallsyms_lookup_buildid+0xc8/0x163<br /> [ 100.899874] ? __sprint_symbol+0x80/0x135<br /> [ 100.903883] ? dm_update_plane_state+0x3f9/0x4d2<br /> [ 100.908500] ? symbol_string+0xb7/0xde<br /> [ 100.912250] ? number+0x145/0x29b<br /> [ 100.915566] ? vsnprintf+0x341/0x5ff<br /> [ 100.919141] ? desc_read_finalized_seq+0x39/0x87<br /> [ 100.923755] ? update_load_avg+0x1b9/0x607<br /> [ 100.927849] ? compute_mst_dsc_configs_for_state+0x7d/0xd5b<br /> [ 100.933416] ? fetch_pipe_params+0xa4d/0xd0c<br /> [ 100.937686] ? dc_fpu_end+0x3d/0xa8<br /> [ 100.941175] dml_get_voltage_level+0x16b/0x180<br /> [ 100.945619] dcn30_internal_validate_bw+0x10e/0x89b<br /> [ 100.950495] ? dcn31_validate_bandwidth+0x68/0x1fc<br /> [ 100.955285] ? resource_build_scaling_params+0x98b/0xb8c<br /> [ 100.960595] ? dcn31_validate_bandwidth+0x68/0x1fc<br /> [ 100.965384] dcn31_validate_bandwidth+0x9a/0x1fc<br /> [ 100.970001] dc_validate_global_state+0x238/0x295<br /> [ 100.974703] amdgpu_dm_atomic_check+0x9c1/0xbce<br /> [ 100.979235] ? _printk+0x59/0x73<br /> [ 100.982467] drm_atomic_check_only+0x403/0x78b<br /> [ 100.986912] drm_mode_atomic_ioctl+0x49b/0x546<br /> [ 100.991358] ? drm_ioctl+0x1c1/0x3b3<br /> [ 100.994936] ? drm_atomic_set_property+0x92a/0x92a<br /> [ 100.999725] drm_ioctl_kernel+0xdc/0x149<br /> [ 101.003648] drm_ioctl+0x27f/0x3b3<br /> [ 101.007051] ? drm_atomic_set_property+0x92a/0x92a<br /> [ 101.011842] amdgpu_drm_ioctl+0x49/0x7d<br /> [ 101.015679] __se_sys_ioctl+0x7c/0xb8<br /> [ 101.015685] do_syscall_64+0x5f/0xb8<br /> [ 101.015690] ? __irq_exit_rcu+0x34/0x96<br /> <br /> [How]<br /> It calles populate_dml_pipes which uses doubles to initialize.<br /> Adding FPU protection avoids context switch and probable loss of vba context<br /> as there is potential contention while drm debug logs are enabled.