Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "ALSA: firewire-lib: operate for period elapse event in process context"<br /> <br /> Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event<br /> in process context") removed the process context workqueue from<br /> amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove<br /> its overhead.<br /> <br /> With RME Fireface 800, this lead to a regression since<br /> Kernels 5.14.0, causing an AB/BA deadlock competition for the<br /> substream lock with eventual system freeze under ALSA operation:<br /> <br /> thread 0:<br /> * (lock A) acquire substream lock by<br /> snd_pcm_stream_lock_irq() in<br /> snd_pcm_status64()<br /> * (lock B) wait for tasklet to finish by calling<br /> tasklet_unlock_spin_wait() in<br /> tasklet_disable_in_atomic() in<br /> ohci_flush_iso_completions() of ohci.c<br /> <br /> thread 1:<br /> * (lock B) enter tasklet<br /> * (lock A) attempt to acquire substream lock,<br /> waiting for it to be released:<br /> snd_pcm_stream_lock_irqsave() in<br /> snd_pcm_period_elapsed() in<br /> update_pcm_pointers() in<br /> process_ctx_payloads() in<br /> process_rx_packets() of amdtp-stream.c<br /> <br /> ? tasklet_unlock_spin_wait<br /> <br /> <br /> ohci_flush_iso_completions firewire_ohci<br /> amdtp_domain_stream_pcm_pointer snd_firewire_lib<br /> snd_pcm_update_hw_ptr0 snd_pcm<br /> snd_pcm_status64 snd_pcm<br /> <br /> ? native_queued_spin_lock_slowpath<br /> <br /> <br /> _raw_spin_lock_irqsave<br /> snd_pcm_period_elapsed snd_pcm<br /> process_rx_packets snd_firewire_lib<br /> irq_target_callback snd_firewire_lib<br /> handle_it_packet firewire_ohci<br /> context_tasklet firewire_ohci<br /> <br /> Restore the process context work queue to prevent deadlock<br /> AB/BA deadlock competition for ALSA substream lock of<br /> snd_pcm_stream_lock_irq() in snd_pcm_status64()<br /> and snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed().<br /> <br /> revert commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period<br /> elapse event in process context")<br /> <br /> Replace inline description to prevent future deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: add missing condition check for existence of mapped data<br /> <br /> nvme_map_data() is called when request has physical segments, hence<br /> the nvme_unmap_data() should have same condition to avoid dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: sprd: Avoid NULL deref in sprd_iommu_hw_en<br /> <br /> In sprd_iommu_cleanup() before calling function sprd_iommu_hw_en()<br /> dom-&gt;sdev is equal to NULL, which leads to null dereference.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: Fix a use after free in hfcmulti_tx()<br /> <br /> Don&amp;#39;t dereference *sp after calling dev_kfree_skb(*sp).

The BackWPup plugin for WordPress is vulnerable to Directory Traversal in versions up to, and including, 4.0.1 via the job-specific backup folder. This allows authenticated attackers to store backups in arbitrary folders on the server provided they can be written to by the server. Additionally, default settings will place an index.php and a .htaccess file into the chosen directory (unless already present) when the first backup job is run that are intended to prevent directory listing and file access. This means that an attacker could set the backup directory to the root of another site in a shared environment and thus disable that site.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Validate passed in drm syncobj handles in the performance extension<br /> <br /> If userspace provides an unknown or invalid handle anywhere in the handle<br /> array the rest of the driver will not handle that well.<br /> <br /> Fix it by checking handle was looked up successfully or otherwise fail the<br /> extension by jumping into the existing unwind.<br /> <br /> (cherry picked from commit a546b7e4d73c23838d7e4d2c92882b3ca902d213)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Validate passed in drm syncobj handles in the timestamp extension<br /> <br /> If userspace provides an unknown or invalid handle anywhere in the handle<br /> array the rest of the driver will not handle that well.<br /> <br /> Fix it by checking handle was looked up successfully or otherwise fail the<br /> extension by jumping into the existing unwind.<br /> <br /> (cherry picked from commit 8d1276d1b8f738c3afe1457d4dff5cc66fc848a3)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix potential memory leak in the performance extension<br /> <br /> If fetching of userspace memory fails during the main loop, all drm sync<br /> objs looked up until that point will be leaked because of the missing<br /> drm_syncobj_put.<br /> <br /> Fix it by exporting and using a common cleanup helper.<br /> <br /> (cherry picked from commit 484de39fa5f5b7bd0c5f2e2c5265167250ef7501)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Fix potential memory leak in the timestamp extension<br /> <br /> If fetching of userspace memory fails during the main loop, all drm sync<br /> objs looked up until that point will be leaked because of the missing<br /> drm_syncobj_put.<br /> <br /> Fix it by exporting and using a common cleanup helper.<br /> <br /> (cherry picked from commit 753ce4fea62182c77e1691ab4f9022008f25b62e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Prevent out of bounds access in performance query extensions<br /> <br /> Check that the number of perfmons userspace is passing in the copy and<br /> reset extensions is not greater than the internal kernel storage where<br /> the ids will be copied into.<br /> <br /> (cherry picked from commit f32b5128d2c440368b5bf3a7a356823e235caabb)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: make cow_file_range_inline() honor locked_page on error<br /> <br /> The btrfs buffered write path runs through __extent_writepage() which<br /> has some tricky return value handling for writepage_delalloc().<br /> Specifically, when that returns 1, we exit, but for other return values<br /> we continue and end up calling btrfs_folio_end_all_writers(). If the<br /> folio has been unlocked (note that we check the PageLocked bit at the<br /> start of __extent_writepage()), this results in an assert panic like<br /> this one from syzbot:<br /> <br /> BTRFS: error (device loop0 state EAL) in free_log_tree:3267: errno=-5 IO failure<br /> BTRFS warning (device loop0 state EAL): Skipping commit of aborted transaction.<br /> BTRFS: error (device loop0 state EAL) in cleanup_transaction:2018: errno=-5 IO failure<br /> assertion failed: folio_test_locked(folio), in fs/btrfs/subpage.c:871<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/subpage.c:871!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 1 PID: 5090 Comm: syz-executor225 Not tainted<br /> 6.10.0-syzkaller-05505-gb1bc554e009e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS<br /> Google 06/27/2024<br /> RIP: 0010:btrfs_folio_end_all_writers+0x55b/0x610 fs/btrfs/subpage.c:871<br /> Code: e9 d3 fb ff ff e8 25 22 c2 fd 48 c7 c7 c0 3c 0e 8c 48 c7 c6 80 3d<br /> 0e 8c 48 c7 c2 60 3c 0e 8c b9 67 03 00 00 e8 66 47 ad 07 90 0b e8<br /> 6e 45 b0 07 4c 89 ff be 08 00 00 00 e8 21 12 25 fe 4c 89<br /> RSP: 0018:ffffc900033d72e0 EFLAGS: 00010246<br /> RAX: 0000000000000045 RBX: 00fff0000000402c RCX: 663b7a08c50a0a00<br /> RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000<br /> RBP: ffffc900033d73b0 R08: ffffffff8176b98c R09: 1ffff9200067adfc<br /> R10: dffffc0000000000 R11: fffff5200067adfd R12: 0000000000000001<br /> R13: dffffc0000000000 R14: 0000000000000000 R15: ffffea0001cbee80<br /> FS: 0000000000000000(0000) GS:ffff8880b9500000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f5f076012f8 CR3: 000000000e134000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __extent_writepage fs/btrfs/extent_io.c:1597 [inline]<br /> extent_write_cache_pages fs/btrfs/extent_io.c:2251 [inline]<br /> btrfs_writepages+0x14d7/0x2760 fs/btrfs/extent_io.c:2373<br /> do_writepages+0x359/0x870 mm/page-writeback.c:2656<br /> filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397<br /> __filemap_fdatawrite_range mm/filemap.c:430 [inline]<br /> __filemap_fdatawrite mm/filemap.c:436 [inline]<br /> filemap_flush+0xdf/0x130 mm/filemap.c:463<br /> btrfs_release_file+0x117/0x130 fs/btrfs/file.c:1547<br /> __fput+0x24a/0x8a0 fs/file_table.c:422<br /> task_work_run+0x24f/0x310 kernel/task_work.c:222<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0xa2f/0x27f0 kernel/exit.c:877<br /> do_group_exit+0x207/0x2c0 kernel/exit.c:1026<br /> __do_sys_exit_group kernel/exit.c:1037 [inline]<br /> __se_sys_exit_group kernel/exit.c:1035 [inline]<br /> __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1035<br /> x64_sys_call+0x2634/0x2640<br /> arch/x86/include/generated/asm/syscalls_64.h:232<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5f075b70c9<br /> Code: Unable to access opcode bytes at<br /> 0x7f5f075b709f.<br /> <br /> I was hitting the same issue by doing hundreds of accelerated runs of<br /> generic/475, which also hits IO errors by design.<br /> <br /> I instrumented that reproducer with bpftrace and found that the<br /> undesirable folio_unlock was coming from the following callstack:<br /> <br /> folio_unlock+5<br /> __process_pages_contig+475<br /> cow_file_range_inline.constprop.0+230<br /> cow_file_range+803<br /> btrfs_run_delalloc_range+566<br /> writepage_delalloc+332<br /> __extent_writepage # inlined in my stacktrace, but I added it here<br /> extent_write_cache_pages+622<br /> <br /> Looking at the bisected-to pa<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> protect the fetch of -&gt;fd[fd] in do_dup2() from mispredictions<br /> <br /> both callers have verified that fd is not greater than -&gt;max_fds;<br /> however, misprediction might end up with<br /> tofree = fdt-&gt;fd[fd];<br /> being speculatively executed. That&amp;#39;s wrong for the same reasons<br /> why it&amp;#39;s wrong in close_fd()/file_close_fd_locked(); the same<br /> solution applies - array_index_nospec(fd, fdt-&gt;max_fds) could differ<br /> from fd only in case of speculative execution on mispredicted path.