Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: double hook unregistration in netns path<br /> <br /> __nft_release_hooks() is called from pre_netns exit path which<br /> unregisters the hooks, then the NETDEV_UNREGISTER event is triggered<br /> which unregisters the hooks again.<br /> <br /> [ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270<br /> [...]<br /> [ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27<br /> [ 565.253682] Workqueue: netns cleanup_net<br /> [ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270<br /> [...]<br /> [ 565.297120] Call Trace:<br /> [ 565.300900] <br /> [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables]<br /> [ 565.308518] raw_notifier_call_chain+0x63/0x80<br /> [ 565.312386] unregister_netdevice_many+0x54f/0xb50<br /> <br /> Unregister and destroy netdev hook from netns pre_exit via kfree_rcu<br /> so the NETDEV_UNREGISTER path see unregistered hooks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Drop WARNs that assert a triple fault never "escapes" from L2<br /> <br /> Remove WARNs that sanity check that KVM never lets a triple fault for L2<br /> escape and incorrectly end up in L1. In normal operation, the sanity<br /> check is perfectly valid, but it incorrectly assumes that it&amp;#39;s impossible<br /> for userspace to induce KVM_REQ_TRIPLE_FAULT without bouncing through<br /> KVM_RUN (which guarantees kvm_check_nested_state() will see and handle<br /> the triple fault).<br /> <br /> The WARN can currently be triggered if userspace injects a machine check<br /> while L2 is active and CR4.MCE=0. And a future fix to allow save/restore<br /> of KVM_REQ_TRIPLE_FAULT, e.g. so that a synthesized triple fault isn&amp;#39;t<br /> lost on migration, will make it trivially easy for userspace to trigger<br /> the WARN.<br /> <br /> Clearing KVM_REQ_TRIPLE_FAULT when forcibly leaving guest mode is<br /> tempting, but wrong, especially if/when the request is saved/restored,<br /> e.g. if userspace restores events (including a triple fault) and then<br /> restores nested state (which may forcibly leave guest mode). Ignoring<br /> the fact that KVM doesn&amp;#39;t currently provide the necessary APIs, it&amp;#39;s<br /> userspace&amp;#39;s responsibility to manage pending events during save/restore.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 7 PID: 1399 at arch/x86/kvm/vmx/nested.c:4522 nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 7 PID: 1399 Comm: state_test Not tainted 5.17.0-rc3+ #808<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:nested_vmx_vmexit+0x7fe/0xd90 [kvm_intel]<br /> Call Trace:<br /> <br /> vmx_leave_nested+0x30/0x40 [kvm_intel]<br /> vmx_set_nested_state+0xca/0x3e0 [kvm_intel]<br /> kvm_arch_vcpu_ioctl+0xf49/0x13e0 [kvm]<br /> kvm_vcpu_ioctl+0x4b9/0x660 [kvm]<br /> __x64_sys_ioctl+0x83/0xb0<br /> do_syscall_64+0x3b/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: check if cluster num is valid<br /> <br /> Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap.<br /> This was triggered by reproducer calling truncute with size 0,<br /> which causes the following trace:<br /> <br /> BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174<br /> Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365<br /> <br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118<br /> print_address_description+0x81/0x3c0 mm/kasan/report.c:233<br /> __kasan_report mm/kasan/report.c:419 [inline]<br /> kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436<br /> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309<br /> exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174<br /> exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181<br /> __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217<br /> exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243<br /> exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339<br /> notify_change+0xb76/0xe10 fs/attr.c:336<br /> do_truncate+0x1ea/0x2d0 fs/open.c:65<br /> <br /> Move the is_valid_cluster() helper from fatent.c to a common<br /> header to make it reusable in other *.c files. And add is_valid_cluster()<br /> to validate if cluster number is within valid range in exfat_clear_bitmap()<br /> and exfat_set_bitmap().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: re-fetch conntrack after insertion<br /> <br /> In case the conntrack is clashing, insertion can free skb-&gt;_nfct and<br /> set skb-&gt;_nfct to the already-confirmed entry.<br /> <br /> This wasn&amp;#39;t found before because the conntrack entry and the extension<br /> space used to free&amp;#39;d after an rcu grace period, plus the race needs<br /> events enabled to trigger.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Use __try_cmpxchg_user() to update guest PTE A/D bits<br /> <br /> Use the recently introduced __try_cmpxchg_user() to update guest PTE A/D<br /> bits instead of mapping the PTE into kernel address space. The VM_PFNMAP<br /> path is broken as it assumes that vm_pgoff is the base pfn of the mapped<br /> VMA range, which is conceptually wrong as vm_pgoff is the offset relative<br /> to the file and has nothing to do with the pfn. The horrific hack worked<br /> for the original use case (backing guest memory with /dev/mem), but leads<br /> to accessing "random" pfns for pretty much any other VM_PFNMAP case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Use kzalloc for sev ioctl interfaces to prevent kernel data leak<br /> <br /> For some sev ioctl interfaces, the length parameter that is passed maybe<br /> less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data<br /> that PSP firmware returns. In this case, kmalloc will allocate memory<br /> that is the size of the input rather than the size of the data.<br /> Since PSP firmware doesn&amp;#39;t fully overwrite the allocated buffer, these<br /> sev ioctl interface may return uninitialized kernel slab memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential double free during failed mount<br /> <br /> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg()<br /> <br /> In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard<br /> lockup call trace hangs the system.<br /> <br /> Call Trace:<br /> _raw_spin_lock_irqsave+0x32/0x40<br /> lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc]<br /> lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc]<br /> lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc]<br /> lpfc_els_flush_cmd+0x43c/0x670 [lpfc]<br /> lpfc_els_flush_all_cmd+0x37/0x60 [lpfc]<br /> lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc]<br /> lpfc_do_work+0x1485/0x1d70 [lpfc]<br /> kthread+0x112/0x130<br /> ret_from_fork+0x1f/0x40<br /> Kernel panic - not syncing: Hard LOCKUP<br /> <br /> The same CPU tries to claim the phba-&gt;port_list_lock twice.<br /> <br /> Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and<br /> lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need<br /> to take the phba-&gt;port_list_lock within lpfc_dmp_dbg().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: fix the warning of dev_wake in mhi_pm_disable_transition()<br /> <br /> When test device recovery with below command, it has warning in message<br /> as below.<br /> echo assert &gt; /sys/kernel/debug/ath11k/wcn6855\ hw2.0/simulate_fw_crash<br /> echo assert &gt; /sys/kernel/debug/ath11k/qca6390\ hw2.0/simulate_fw_crash<br /> <br /> warning message:<br /> [ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash<br /> [ 1968.471364] ieee80211 phy0: Hardware restart was requested<br /> [ 1968.511305] ------------[ cut here ]------------<br /> [ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi]<br /> [ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core<br /> [ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579<br /> [ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021<br /> [ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi]<br /> [ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi]<br /> [ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89<br /> [ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286<br /> [ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922<br /> [ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24<br /> [ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27<br /> [ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac<br /> [ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24<br /> [ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000<br /> [ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0<br /> [ 1968.512587] Call Trace:<br /> [ 1968.512672] <br /> [ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40<br /> [ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi]<br /> [ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi]<br /> [ 1968.513063] process_one_work+0x86a/0x1400<br /> [ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230<br /> [ 1968.513312] ? move_linked_works+0x125/0x290<br /> [ 1968.513416] worker_thread+0x6db/0xf60<br /> [ 1968.513536] ? process_one_work+0x1400/0x1400<br /> [ 1968.513627] kthread+0x241/0x2d0<br /> [ 1968.513733] ? kthread_complete_and_exit+0x20/0x20<br /> [ 1968.513821] ret_from_fork+0x22/0x30<br /> [ 1968.513924] <br /> <br /> Reason is mhi_deassert_dev_wake() from mhi_device_put() is called<br /> but mhi_assert_dev_wake() from __mhi_device_get_sync() is not called<br /> in progress of recovery. Commit 8e0559921f9a ("bus: mhi: core:<br /> Skip device wake in error or shutdown state") add check for the<br /> pm_state of mhi in __mhi_device_get_sync(), and the pm_state is not<br /> the normal state untill recovery is completed, so it leads the<br /> dev_wake is not 0 and above warning print in mhi_pm_disable_transition()<br /> while checking mhi_cntrl-&gt;dev_wake.<br /> <br /> Add check in ath11k_pci_write32()/ath11k_pci_read32() to skip call<br /> mhi_device_put() if mhi_device_get_sync() does not really do wake,<br /> then the warning gone.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipw2x00: Fix potential NULL dereference in libipw_xmit()<br /> <br /> crypt and crypt-&gt;ops could be null, so we need to checking null<br /> before dereference

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 /> 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---