Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race in read_extent_buffer_pages()<br /> <br /> There are reports from tree-checker that detects corrupted nodes,<br /> without any obvious pattern so possibly an overwrite in memory.<br /> After some debugging it turns out there&amp;#39;s a race when reading an extent<br /> buffer the uptodate status can be missed.<br /> <br /> To prevent concurrent reads for the same extent buffer,<br /> read_extent_buffer_pages() performs these checks:<br /> <br /> /* (1) */<br /> if (test_bit(EXTENT_BUFFER_UPTODATE, &amp;eb-&gt;bflags))<br /> return 0;<br /> <br /> /* (2) */<br /> if (test_and_set_bit(EXTENT_BUFFER_READING, &amp;eb-&gt;bflags))<br /> goto done;<br /> <br /> At this point, it seems safe to start the actual read operation. Once<br /> that completes, end_bbio_meta_read() does<br /> <br /> /* (3) */<br /> set_extent_buffer_uptodate(eb);<br /> <br /> /* (4) */<br /> clear_bit(EXTENT_BUFFER_READING, &amp;eb-&gt;bflags);<br /> <br /> Normally, this is enough to ensure only one read happens, and all other<br /> callers wait for it to finish before returning. Unfortunately, there is<br /> a racey interleaving:<br /> <br /> Thread A | Thread B | Thread C<br /> ---------+----------+---------<br /> (1) | |<br /> | (1) |<br /> (2) | |<br /> (3) | |<br /> (4) | |<br /> | (2) |<br /> | | (1)<br /> <br /> When this happens, thread B kicks of an unnecessary read. Worse, thread<br /> C will see UPTODATE set and return immediately, while the read from<br /> thread B is still in progress. This race could result in tree-checker<br /> errors like this as the extent buffer is concurrently modified:<br /> <br /> BTRFS critical (device dm-0): corrupted node, root=256<br /> block=8550954455682405139 owner mismatch, have 11858205567642294356<br /> expect [256, 18446744073709551360]<br /> <br /> Fix it by testing UPTODATE again after setting the READING bit, and if<br /> it&amp;#39;s been set, skip the unnecessary read.<br /> <br /> [ minor update of changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Prevent crash when disable stream<br /> <br /> [Why]<br /> Disabling stream encoder invokes a function that no longer exists.<br /> <br /> [How]<br /> Check if the function declaration is NULL in disable stream encoder.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: fix panic in kdump kernel<br /> <br /> Check if get_next_variable() is actually valid pointer before<br /> calling it. In kdump kernel this method is set to NULL that causes<br /> panic during the kexec-ed kernel boot.<br /> <br /> Tested with QEMU and OVMF firmware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD<br /> <br /> Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and<br /> commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a<br /> per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in<br /> order to avoid unnecessary writes to the MSR.<br /> <br /> On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which<br /> wipes out any stale state. But the per CPU cached xfd value is not<br /> reset, which brings them out of sync.<br /> <br /> As a consequence a subsequent xfd_update_state() might fail to update<br /> the MSR which in turn can result in XRSTOR raising a #NM in kernel<br /> space, which crashes the kernel.<br /> <br /> To fix this, introduce xfd_set_state() to write xfd_state together<br /> with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.

An arbitrary file upload vulnerability in the component /include/file.php of lylme_spage v1.9.5 allows attackers to execute arbitrary code via uploading a crafted file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix deadlock while reading mqd from debugfs<br /> <br /> An errant disk backup on my desktop got into debugfs and triggered the<br /> following deadlock scenario in the amdgpu debugfs files. The machine<br /> also hard-resets immediately after those lines are printed (although I<br /> wasn&amp;#39;t able to reproduce that part when reading by hand):<br /> <br /> [ 1318.016074][ T1082] ======================================================<br /> [ 1318.016607][ T1082] WARNING: possible circular locking dependency detected<br /> [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted<br /> [ 1318.017598][ T1082] ------------------------------------------------------<br /> [ 1318.018096][ T1082] tar/1082 is trying to acquire lock:<br /> [ 1318.018585][ T1082] ffff98c44175d6a0 (&amp;mm-&gt;mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80<br /> [ 1318.019084][ T1082]<br /> [ 1318.019084][ T1082] but task is already holding lock:<br /> [ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]<br /> [ 1318.020607][ T1082]<br /> [ 1318.020607][ T1082] which lock already depends on the new lock.<br /> [ 1318.020607][ T1082]<br /> [ 1318.022081][ T1082]<br /> [ 1318.022081][ T1082] the existing dependency chain (in reverse order) is:<br /> [ 1318.023083][ T1082]<br /> [ 1318.023083][ T1082] -&gt; #2 (reservation_ww_class_mutex){+.+.}-{3:3}:<br /> [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0<br /> [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90<br /> [ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330<br /> [ 1318.025683][ T1082] do_one_initcall+0x6a/0x350<br /> [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310<br /> [ 1318.026728][ T1082] kernel_init+0x15/0x1a0<br /> [ 1318.027242][ T1082] ret_from_fork+0x2c/0x40<br /> [ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20<br /> [ 1318.028281][ T1082]<br /> [ 1318.028281][ T1082] -&gt; #1 (reservation_ww_class_acquire){+.+.}-{0:0}:<br /> [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330<br /> [ 1318.029790][ T1082] do_one_initcall+0x6a/0x350<br /> [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310<br /> [ 1318.030722][ T1082] kernel_init+0x15/0x1a0<br /> [ 1318.031168][ T1082] ret_from_fork+0x2c/0x40<br /> [ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20<br /> [ 1318.032011][ T1082]<br /> [ 1318.032011][ T1082] -&gt; #0 (&amp;mm-&gt;mmap_lock){++++}-{3:3}:<br /> [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680<br /> [ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0<br /> [ 1318.033487][ T1082] __might_fault+0x58/0x80<br /> [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu]<br /> [ 1318.034181][ T1082] full_proxy_read+0x55/0x80<br /> [ 1318.034487][ T1082] vfs_read+0xa7/0x360<br /> [ 1318.034788][ T1082] ksys_read+0x70/0xf0<br /> [ 1318.035085][ T1082] do_syscall_64+0x94/0x180<br /> [ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e<br /> [ 1318.035664][ T1082]<br /> [ 1318.035664][ T1082] other info that might help us debug this:<br /> [ 1318.035664][ T1082]<br /> [ 1318.036487][ T1082] Chain exists of:<br /> [ 1318.036487][ T1082] &amp;mm-&gt;mmap_lock --&gt; reservation_ww_class_acquire --&gt; reservation_ww_class_mutex<br /> [ 1318.036487][ T1082]<br /> [ 1318.037310][ T1082] Possible unsafe locking scenario:<br /> [ 1318.037310][ T1082]<br /> [ 1318.037838][ T1082] CPU0 CPU1<br /> [ 1318.038101][ T1082] ---- ----<br /> [ 1318.038350][ T1082] lock(reservation_ww_class_mutex);<br /> [ 1318.038590][ T1082] lock(reservation_ww_class_acquire);<br /> [ 1318.038839][ T1082] lock(reservation_ww_class_mutex);<br /> [ 1318.039083][ T1082] rlock(&amp;mm-&gt;mmap_lock);<br /> [ 1318.039328][ T1082]<br /> [ 1318.039328][ T1082] *** DEADLOCK ***<br /> [ 1318.039328][ T1082]<br /> [ 1318.040029][ T1082] 1 lock held by tar/1082:<br /> [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu]<br /> [ 1318.040560][ T1082]<br /> [ 1318.040560][ T1082] stack backtrace:<br /> [<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: cachestat: fix two shmem bugs<br /> <br /> When cachestat on shmem races with swapping and invalidation, there<br /> are two possible bugs:<br /> <br /> 1) A swapin error can have resulted in a poisoned swap entry in the<br /> shmem inode&amp;#39;s xarray. Calling get_shadow_from_swap_cache() on it<br /> will result in an out-of-bounds access to swapper_spaces[].<br /> <br /> Validate the entry with non_swap_entry() before going further.<br /> <br /> 2) When we find a valid swap entry in the shmem&amp;#39;s inode, the shadow<br /> entry in the swapcache might not exist yet: swap IO is still in<br /> progress and we&amp;#39;re before __remove_mapping; swapin, invalidation,<br /> or swapoff have removed the shadow from swapcache after we saw the<br /> shmem swap entry.<br /> <br /> This will send a NULL to workingset_test_recent(). The latter<br /> purely operates on pointer bits, so it won&amp;#39;t crash - node 0, memcg<br /> ID 0, eviction timestamp 0, etc. are all valid inputs - but it&amp;#39;s a<br /> bogus test. In theory that could result in a false "recently<br /> evicted" count.<br /> <br /> Such a false positive wouldn&amp;#39;t be the end of the world. But for<br /> code clarity and (future) robustness, be explicit about this case.<br /> <br /> Bail on get_shadow_from_swap_cache() returning NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ll_temac: platform_get_resource replaced by wrong function<br /> <br /> The function platform_get_resource was replaced with<br /> devm_platform_ioremap_resource_byname and is called using 0 as name.<br /> <br /> This eventually ends up in platform_get_resource_byname in the call<br /> stack, where it causes a null pointer in strcmp.<br /> <br /> if (type == resource_type(r) &amp;&amp; !strcmp(r-&gt;name, name))<br /> <br /> It should have been replaced with devm_platform_ioremap_resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix hang/underflow when transitioning to ODM4:1<br /> <br /> [Why]<br /> Under some circumstances, disabling an OPTC and attempting to reclaim<br /> its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs<br /> not being properly disconnected from the disabled OPTC.<br /> <br /> [How]<br /> Ensure that all OPPs are unassigned from an OPTC when it gets disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix a debugfs null pointer error<br /> <br /> [WHY &amp; HOW]<br /> Check whether get_subvp_en() callback exists before calling it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: virtio: Free driver_override when rpmsg_remove()<br /> <br /> Free driver_override when rpmsg_remove(), otherwise<br /> the following memory leak will occur:<br /> <br /> unreferenced object 0xffff0000d55d7080 (size 128):<br /> comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)<br /> hex dump (first 32 bytes):<br /> 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1f8/0x320<br /> [] __kmalloc_node_track_caller+0x44/0x70<br /> [] kstrndup+0x4c/0x90<br /> [] driver_set_override+0xd0/0x164<br /> [] rpmsg_register_device_override+0x98/0x170<br /> [] rpmsg_ns_register_device+0x24/0x30<br /> [] rpmsg_probe+0x2e0/0x3ec<br /> [] virtio_dev_probe+0x1c0/0x280<br /> [] really_probe+0xbc/0x2dc<br /> [] __driver_probe_device+0x78/0xe0<br /> [] driver_probe_device+0xd8/0x160<br /> [] __device_attach_driver+0xb8/0x140<br /> [] bus_for_each_drv+0x7c/0xd4<br /> [] __device_attach+0x9c/0x19c<br /> [] device_initial_probe+0x14/0x20<br /> [] bus_probe_device+0xa0/0xac

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pipe: wakeup wr_wait after setting max_usage<br /> <br /> Commit c73be61cede5 ("pipe: Add general notification queue support") a<br /> regression was introduced that would lock up resized pipes under certain<br /> conditions. See the reproducer in [1].<br /> <br /> The commit resizing the pipe ring size was moved to a different<br /> function, doing that moved the wakeup for pipe-&gt;wr_wait before actually<br /> raising pipe-&gt;max_usage. If a pipe was full before the resize occured it<br /> would result in the wakeup never actually triggering pipe_write.<br /> <br /> Set @max_usage and @nr_accounted before waking writers if this isn&amp;#39;t a<br /> watch queue.<br /> <br /> [Christian Brauner : rewrite to account for watch queues]