Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix deadlock between concurrent dio writes when low on free data space<br /> <br /> When reserving data space for a direct IO write we can end up deadlocking<br /> if we have multiple tasks attempting a write to the same file range, there<br /> are multiple extents covered by that file range, we are low on available<br /> space for data and the writes don&amp;#39;t expand the inode&amp;#39;s i_size.<br /> <br /> The deadlock can happen like this:<br /> <br /> 1) We have a file with an i_size of 1M, at offset 0 it has an extent with<br /> a size of 128K and at offset 128K it has another extent also with a<br /> size of 128K;<br /> <br /> 2) Task A does a direct IO write against file range [0, 256K), and because<br /> the write is within the i_size boundary, it takes the inode&amp;#39;s lock (VFS<br /> level) in shared mode;<br /> <br /> 3) Task A locks the file range [0, 256K) at btrfs_dio_iomap_begin(), and<br /> then gets the extent map for the extent covering the range [0, 128K).<br /> At btrfs_get_blocks_direct_write(), it creates an ordered extent for<br /> that file range ([0, 128K));<br /> <br /> 4) Before returning from btrfs_dio_iomap_begin(), it unlocks the file<br /> range [0, 256K);<br /> <br /> 5) Task A executes btrfs_dio_iomap_begin() again, this time for the file<br /> range [128K, 256K), and locks the file range [128K, 256K);<br /> <br /> 6) Task B starts a direct IO write against file range [0, 256K) as well.<br /> It also locks the inode in shared mode, as it&amp;#39;s within the i_size limit,<br /> and then tries to lock file range [0, 256K). It is able to lock the<br /> subrange [0, 128K) but then blocks waiting for the range [128K, 256K),<br /> as it is currently locked by task A;<br /> <br /> 7) Task A enters btrfs_get_blocks_direct_write() and tries to reserve data<br /> space. Because we are low on available free space, it triggers the<br /> async data reclaim task, and waits for it to reserve data space;<br /> <br /> 8) The async reclaim task decides to wait for all existing ordered extents<br /> to complete (through btrfs_wait_ordered_roots()).<br /> It finds the ordered extent previously created by task A for the file<br /> range [0, 128K) and waits for it to complete;<br /> <br /> 9) The ordered extent for the file range [0, 128K) can not complete<br /> because it blocks at btrfs_finish_ordered_io() when trying to lock the<br /> file range [0, 128K).<br /> <br /> This results in a deadlock, because:<br /> <br /> - task B is holding the file range [0, 128K) locked, waiting for the<br /> range [128K, 256K) to be unlocked by task A;<br /> <br /> - task A is holding the file range [128K, 256K) locked and it&amp;#39;s waiting<br /> for the async data reclaim task to satisfy its space reservation<br /> request;<br /> <br /> - the async data reclaim task is waiting for ordered extent [0, 128K)<br /> to complete, but the ordered extent can not complete because the<br /> file range [0, 128K) is currently locked by task B, which is waiting<br /> on task A to unlock file range [128K, 256K) and task A waiting<br /> on the async data reclaim task.<br /> <br /> This results in a deadlock between 4 task: task A, task B, the async<br /> data reclaim task and the task doing ordered extent completion (a work<br /> queue task).<br /> <br /> This type of deadlock can sporadically be triggered by the test case<br /> generic/300 from fstests, and results in a stack trace like the following:<br /> <br /> [12084.033689] INFO: task kworker/u16:7:123749 blocked for more than 241 seconds.<br /> [12084.034877] Not tainted 5.18.0-rc2-btrfs-next-115 #1<br /> [12084.035562] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [12084.036548] task:kworker/u16:7 state:D stack: 0 pid:123749 ppid: 2 flags:0x00004000<br /> [12084.036554] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]<br /> [12084.036599] Call Trace:<br /> [12084.036601] <br /> [12084.036606] __schedule+0x3cb/0xed0<br /> [12084.036616] schedule+0x4e/0xb0<br /> [12084.036620] btrfs_start_ordered_extent+0x109/0x1c0 [btrfs]<br /> [12084.036651] ? prepare_to_wait_exclusive+0xc0/0xc0<br /> [12084.036659] btrfs_run_ordered_extent_work+0x1a/0x30 [btrfs]<br /> [12084.036688] btrfs_work_helper+0xf8/0x400 [btrfs]<br /> [12084.0367<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix potential array overflow in bpf_trampoline_get_progs()<br /> <br /> The cnt value in the &amp;#39;cnt &gt;= BPF_MAX_TRAMP_PROGS&amp;#39; check does not<br /> include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of<br /> the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline<br /> can exceed BPF_MAX_TRAMP_PROGS.<br /> <br /> When this happens, the assignment &amp;#39;*progs++ = aux-&gt;prog&amp;#39; in<br /> bpf_trampoline_get_progs() will cause progs array overflow as the<br /> progs field in the bpf_tramp_progs struct can only hold at most<br /> BPF_MAX_TRAMP_PROGS bpf programs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails<br /> <br /> In mce_threshold_create_device(), if threshold_create_bank() fails, the<br /> previously allocated threshold banks array @bp will be leaked because<br /> the call to mce_threshold_remove_device() will not free it.<br /> <br /> This happens because mce_threshold_remove_device() fetches the pointer<br /> through the threshold_banks per-CPU variable but bp is written there<br /> only after the bank creation is successful, and not before, when<br /> threshold_create_bank() fails.<br /> <br /> Add a helper which unwinds all the bank creation work previously done<br /> and pass into it the previously allocated threshold banks array for<br /> freeing.<br /> <br /> [ bp: Massage. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: provide block_invalidate_folio to fix memory leak<br /> <br /> The ntfs3 filesystem lacks the &amp;#39;invalidate_folio&amp;#39; method and it causes<br /> memory leak. If you write to the filesystem and then unmount it, the<br /> cached written data are not freed and they are permanently leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: isp1760: Fix out-of-bounds array access<br /> <br /> Running the driver through kasan gives an interesting splat:<br /> <br /> BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c<br /> Read of size 20 at addr f1db2e64 by task swapper/0/1<br /> (...)<br /> isp1760_register from isp1760_plat_probe+0x1d8/0x220<br /> (...)<br /> <br /> This happens because the loop reading the regmap fields for the<br /> different ISP1760 variants look like this:<br /> <br /> for (i = 0; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Cancel pending work at closing a MIDI substream<br /> <br /> At closing a USB MIDI output substream, there might be still a pending<br /> work, which would eventually access the rawmidi runtime object that is<br /> being released. For fixing the race, make sure to cancel the pending<br /> work at closing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes<br /> <br /> drm_cvt_mode may return NULL and we should check it.<br /> <br /> This bug is found by syzkaller:<br /> <br /> FAULT_INJECTION stacktrace:<br /> [ 168.567394] FAULT_INJECTION: forcing a failure.<br /> name failslab, interval 1, probability 0, space 0, times 1<br /> [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1<br /> [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> [ 168.567408] Call trace:<br /> [ 168.567414] dump_backtrace+0x0/0x310<br /> [ 168.567418] show_stack+0x28/0x38<br /> [ 168.567423] dump_stack+0xec/0x15c<br /> [ 168.567427] should_fail+0x3ac/0x3d0<br /> [ 168.567437] __should_failslab+0xb8/0x120<br /> [ 168.567441] should_failslab+0x28/0xc0<br /> [ 168.567445] kmem_cache_alloc_trace+0x50/0x640<br /> [ 168.567454] drm_mode_create+0x40/0x90<br /> [ 168.567458] drm_cvt_mode+0x48/0xc78<br /> [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]<br /> [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80<br /> [ 168.567492] drm_mode_getconnector+0x2e0/0xa70<br /> [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8<br /> [ 168.567514] drm_ioctl+0x558/0x6d0<br /> [ 168.567522] do_vfs_ioctl+0x160/0xf30<br /> [ 168.567525] ksys_ioctl+0x98/0xd8<br /> [ 168.567530] __arm64_sys_ioctl+0x50/0xc8<br /> [ 168.567536] el0_svc_common+0xc8/0x320<br /> [ 168.567540] el0_svc_handler+0xf8/0x160<br /> [ 168.567544] el0_svc+0x10/0x218<br /> <br /> KASAN stacktrace:<br /> [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]<br /> [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425<br /> [ 168.567566]<br /> [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1<br /> [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015<br /> [ 168.567575] Call trace:<br /> [ 168.567578] dump_backtrace+0x0/0x310<br /> [ 168.567582] show_stack+0x28/0x38<br /> [ 168.567586] dump_stack+0xec/0x15c<br /> [ 168.567591] kasan_report+0x244/0x2f0<br /> [ 168.567594] __asan_load4+0x58/0xb0<br /> [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]<br /> [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80<br /> [ 168.567617] drm_mode_getconnector+0x2e0/0xa70<br /> [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8<br /> [ 168.567624] drm_ioctl+0x558/0x6d0<br /> [ 168.567628] do_vfs_ioctl+0x160/0xf30<br /> [ 168.567632] ksys_ioctl+0x98/0xd8<br /> [ 168.567636] __arm64_sys_ioctl+0x50/0xc8<br /> [ 168.567641] el0_svc_common+0xc8/0x320<br /> [ 168.567645] el0_svc_handler+0xf8/0x160<br /> [ 168.567649] el0_svc+0x10/0x218

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT<br /> <br /> There is a potential memory leak in lpfc_ignore_els_cmpl() and<br /> lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT<br /> (lpfc_rcv_plogi()&amp;#39;s login_mbox).<br /> <br /> Check if cmdiocb-&gt;context_un.mbox was allocated in lpfc_ignore_els_cmpl(),<br /> and then free it back to phba-&gt;mbox_mem_pool along with mbox-&gt;ctx_buf for<br /> service parameters.<br /> <br /> For lpfc_els_rsp_reject() failure, free both the ctx_buf for service<br /> parameters and the login_mbox.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock<br /> <br /> During stress I/O tests with 500+ vports, hard LOCKUP call traces are<br /> observed.<br /> <br /> CPU A:<br /> native_queued_spin_lock_slowpath+0x192<br /> _raw_spin_lock_irqsave+0x32<br /> lpfc_handle_fcp_err+0x4c6<br /> lpfc_fcp_io_cmd_wqe_cmpl+0x964<br /> lpfc_sli4_fp_handle_cqe+0x266<br /> __lpfc_sli4_process_cq+0x105<br /> __lpfc_sli4_hba_process_cq+0x3c<br /> lpfc_cq_poll_hdler+0x16<br /> irq_poll_softirq+0x76<br /> __softirqentry_text_start+0xe4<br /> irq_exit+0xf7<br /> do_IRQ+0x7f<br /> <br /> CPU B:<br /> native_queued_spin_lock_slowpath+0x5b<br /> _raw_spin_lock+0x1c<br /> lpfc_abort_handler+0x13e<br /> scmd_eh_abort_handler+0x85<br /> process_one_work+0x1a7<br /> worker_thread+0x30<br /> kthread+0x112<br /> ret_from_fork+0x1f<br /> <br /> Diagram of lockup:<br /> <br /> CPUA CPUB<br /> ---- ----<br /> lpfc_cmd-&gt;buf_lock<br /> phba-&gt;hbalock<br /> lpfc_cmd-&gt;buf_lock<br /> phba-&gt;hbalock<br /> <br /> Fix by reordering the taking of the lpfc_cmd-&gt;buf_lock and phba-&gt;hbalock in<br /> lpfc_abort_handler routine so that it tries to take the lpfc_cmd-&gt;buf_lock<br /> first before phba-&gt;hbalock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix call trace observed during I/O with CMF enabled<br /> <br /> The following was seen with CMF enabled:<br /> <br /> BUG: using smp_processor_id() in preemptible<br /> code: systemd-udevd/31711<br /> kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc]<br /> kernel: CPU: 12 PID: 31711 Comm: systemd-udevd<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: dump_stack_lvl+0x44/0x57<br /> kernel: check_preemption_disabled+0xbf/0xe0<br /> kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc]<br /> kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc]<br /> <br /> this_cpu_ptr() calls smp_processor_id() in a preemptible context.<br /> <br /> Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: jack: Access input_dev under mutex<br /> <br /> It is possible when using ASoC that input_dev is unregistered while<br /> calling snd_jack_report, which causes NULL pointer dereference.<br /> In order to prevent this serialize access to input_dev using mutex lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtw89: ser: fix CAM leaks occurring in L2 reset<br /> <br /> The CAM, meaning address CAM and bssid CAM here, will get leaks during<br /> SER (system error recover) L2 reset process and ieee80211_restart_hw()<br /> which is called by L2 reset process eventually.<br /> <br /> The normal flow would be like<br /> -&gt; add interface (acquire 1)<br /> -&gt; enter ips (release 1)<br /> -&gt; leave ips (acquire 1)<br /> -&gt; connection (occupy 1) <br /> <br /> The ieee80211_restart_hw() flow (under connection)<br /> -&gt; ieee80211 reconfig<br /> -&gt; add interface (acquire 1)<br /> -&gt; leave ips (acquire 1)<br /> -&gt; connection (occupy (A) + 2) <br /> <br /> Originally, CAM is released before HW restart only if connection is under<br /> security. Now, release CAM whatever connection it is to fix leak in (A).<br /> OTOH, check if CAM is already valid to avoid acquiring multiple times to<br /> fix (B).<br /> <br /> Besides, if AP mode, release address CAM of all stations before HW restart.