Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix corruption during on-line resize<br /> <br /> We observed a corruption during on-line resize of a file system that is<br /> larger than 16 TiB with 4k block size. With having more then 2^32 blocks<br /> resize_inode is turned off by default by mke2fs. The issue can be<br /> reproduced on a smaller file system for convenience by explicitly<br /> turning off resize_inode. An on-line resize across an 8 GiB boundary (the<br /> size of a meta block group in this setup) then leads to a corruption:<br /> <br /> dev=/dev/ # should be &gt;= 16 GiB<br /> mkdir -p /corruption<br /> /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))<br /> mount -t ext4 $dev /corruption<br /> <br /> dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))<br /> sha1sum /corruption/test<br /> # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test<br /> <br /> /sbin/resize2fs $dev $((2*2**21))<br /> # drop page cache to force reload the block from disk<br /> echo 1 &gt; /proc/sys/vm/drop_caches<br /> <br /> sha1sum /corruption/test<br /> # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test<br /> <br /> 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per<br /> block group and 2^6 are the number of block groups that make a meta<br /> block group.<br /> <br /> The last checksum might be different depending on how the file is laid<br /> out across the physical blocks. The actual corruption occurs at physical<br /> block 63*2^15 = 2064384 which would be the location of the backup of the<br /> meta block group&amp;#39;s block descriptor. During the on-line resize the file<br /> system will be converted to meta_bg starting at s_first_meta_bg which is<br /> 2 in the example - meaning all block groups after 16 GiB. However, in<br /> ext4_flex_group_add we might add block groups that are not part of the<br /> first meta block group yet. In the reproducer we achieved this by<br /> substracting the size of a whole block group from the point where the<br /> meta block group would start. This must be considered when updating the<br /> backup block group descriptors to follow the non-meta_bg layout. The fix<br /> is to add a test whether the group to add is already part of the meta<br /> block group or not.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/efistub: Call mixed mode boot services on the firmware&amp;#39;s stack<br /> <br /> Normally, the EFI stub calls into the EFI boot services using the stack<br /> that was live when the stub was entered. According to the UEFI spec,<br /> this stack needs to be at least 128k in size - this might seem large but<br /> all asynchronous processing and event handling in EFI runs from the same<br /> stack and so quite a lot of space may be used in practice.<br /> <br /> In mixed mode, the situation is a bit different: the bootloader calls<br /> the 32-bit EFI stub entry point, which calls the decompressor&amp;#39;s 32-bit<br /> entry point, where the boot stack is set up, using a fixed allocation<br /> of 16k. This stack is still in use when the EFI stub is started in<br /> 64-bit mode, and so all calls back into the EFI firmware will be using<br /> the decompressor&amp;#39;s limited boot stack.<br /> <br /> Due to the placement of the boot stack right after the boot heap, any<br /> stack overruns have gone unnoticed. However, commit<br /> <br /> 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code")<br /> <br /> moved the definition of the boot heap into C code, and now the boot<br /> stack is placed right at the base of BSS, where any overruns will<br /> corrupt the end of the .data section.<br /> <br /> While it would be possible to work around this by increasing the size of<br /> the boot stack, doing so would affect all x86 systems, and mixed mode<br /> systems are a tiny (and shrinking) fraction of the x86 installed base.<br /> <br /> So instead, record the firmware stack pointer value when entering from<br /> the 32-bit firmware, and switch to this stack every time a EFI boot<br /> service call is made.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Mark target gfn of emulated atomic instruction as dirty<br /> <br /> When emulating an atomic access on behalf of the guest, mark the target<br /> gfn dirty if the CMPXCHG by KVM is attempted and doesn&amp;#39;t fault. This<br /> fixes a bug where KVM effectively corrupts guest memory during live<br /> migration by writing to guest memory without informing userspace that the<br /> page is dirty.<br /> <br /> Marking the page dirty got unintentionally dropped when KVM&amp;#39;s emulated<br /> CMPXCHG was converted to do a user access. Before that, KVM explicitly<br /> mapped the guest page into kernel memory, and marked the page dirty during<br /> the unmap phase.<br /> <br /> Mark the page dirty even if the CMPXCHG fails, as the old data is written<br /> back on failure, i.e. the page is still written. The value written is<br /> guaranteed to be the same because the operation is atomic, but KVM&amp;#39;s ABI<br /> is that all writes are dirty logged regardless of the value written. And<br /> more importantly, that&amp;#39;s what KVM did before the buggy commit.<br /> <br /> Huge kudos to the folks on the Cc list (and many others), who did all the<br /> actual work of triaging and debugging.<br /> <br /> base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm snapshot: fix lockup in dm_exception_table_exit<br /> <br /> There was reported lockup when we exit a snapshot with many exceptions.<br /> Fix this by adding "cond_resched" to the loop that frees the exceptions.

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.