Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_sync<br /> <br /> Use-after-free can occur in hci_disconnect_all_sync if a connection is<br /> deleted by concurrent processing of a controller event.<br /> <br /> To prevent this the code now tries to iterate over the list backwards<br /> to ensure the links are cleanup before its parents, also it no longer<br /> relies on a cursor, instead it always uses the last element since<br /> hci_abort_conn_sync is guaranteed to call hci_conn_del.<br /> <br /> UAF crash log:<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in hci_set_powered_sync<br /> (net/bluetooth/hci_sync.c:5424) [bluetooth]<br /> Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124<br /> <br /> CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W<br /> 6.5.0-rc1+ #10<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> 1.16.2-1.fc38 04/01/2014<br /> Workqueue: hci0 hci_cmd_sync_work [bluetooth]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5b/0x90<br /> print_report+0xcf/0x670<br /> ? __virt_addr_valid+0xdd/0x160<br /> ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]<br /> kasan_report+0xa6/0xe0<br /> ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]<br /> ? __pfx_set_powered_sync+0x10/0x10 [bluetooth]<br /> hci_set_powered_sync+0x2c9/0x4a0 [bluetooth]<br /> ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth]<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __pfx_set_powered_sync+0x10/0x10 [bluetooth]<br /> hci_cmd_sync_work+0x137/0x220 [bluetooth]<br /> process_one_work+0x526/0x9d0<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? mark_held_locks+0x1a/0x90<br /> worker_thread+0x92/0x630<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x196/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> Allocated by task 1782:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> hci_conn_add+0xa5/0xa80 [bluetooth]<br /> hci_bind_cis+0x881/0x9b0 [bluetooth]<br /> iso_connect_cis+0x121/0x520 [bluetooth]<br /> iso_sock_connect+0x3f6/0x790 [bluetooth]<br /> __sys_connect+0x109/0x130<br /> __x64_sys_connect+0x40/0x50<br /> do_syscall_64+0x60/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 695:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> kasan_save_free_info+0x2b/0x50<br /> __kasan_slab_free+0x10a/0x180<br /> __kmem_cache_free+0x14d/0x2e0<br /> device_release+0x5d/0xf0<br /> kobject_put+0xdf/0x270<br /> hci_disconn_complete_evt+0x274/0x3a0 [bluetooth]<br /> hci_event_packet+0x579/0x7e0 [bluetooth]<br /> hci_rx_work+0x287/0xaa0 [bluetooth]<br /> process_one_work+0x526/0x9d0<br /> worker_thread+0x92/0x630<br /> kthread+0x196/0x1e0<br /> ret_from_fork+0x2c/0x50<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "f2fs: fix to do sanity check on extent cache correctly"<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> UBSAN: array-index-out-of-bounds in fs/f2fs/f2fs.h:3275:19<br /> index 1409 is out of range for type &amp;#39;__le32[923]&amp;#39; (aka &amp;#39;unsigned int[923]&amp;#39;)<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106<br /> ubsan_epilogue lib/ubsan.c:217 [inline]<br /> __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348<br /> inline_data_addr fs/f2fs/f2fs.h:3275 [inline]<br /> __recover_inline_status fs/f2fs/inode.c:113 [inline]<br /> do_read_inode fs/f2fs/inode.c:480 [inline]<br /> f2fs_iget+0x4730/0x48b0 fs/f2fs/inode.c:604<br /> f2fs_fill_super+0x640e/0x80c0 fs/f2fs/super.c:4601<br /> mount_bdev+0x276/0x3b0 fs/super.c:1391<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> do_new_mount+0x28f/0xae0 fs/namespace.c:3335<br /> do_mount fs/namespace.c:3675 [inline]<br /> __do_sys_mount fs/namespace.c:3884 [inline]<br /> __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The issue was bisected to:<br /> <br /> commit d48a7b3a72f121655d95b5157c32c7d555e44c05<br /> Author: Chao Yu <br /> Date: Mon Jan 9 03:49:20 2023 +0000<br /> <br /> f2fs: fix to do sanity check on extent cache correctly<br /> <br /> The root cause is we applied both v1 and v2 of the patch, v2 is the right<br /> fix, so it needs to revert v1 in order to fix reported issue.<br /> <br /> v1:<br /> commit d48a7b3a72f1 ("f2fs: fix to do sanity check on extent cache correctly")<br /> https://lore.kernel.org/lkml/20230109034920.492914-1-chao@kernel.org/<br /> <br /> v2:<br /> commit 269d11948100 ("f2fs: fix to do sanity check on extent cache correctly")<br /> https://lore.kernel.org/lkml/20230207134808.1827869-1-chao@kernel.org/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Handle lock during peer_id find<br /> <br /> ath12k_peer_find_by_id() requires that the caller hold the<br /> ab-&gt;base_lock. Currently the WBM error path does not hold<br /> the lock and calling that function, leads to the<br /> following lockdep_assert()in QCN9274:<br /> <br /> [105162.160893] ------------[ cut here ]------------<br /> [105162.160916] WARNING: CPU: 3 PID: 0 at drivers/net/wireless/ath/ath12k/peer.c:71 ath12k_peer_find_by_id+0x52/0x60 [ath12k]<br /> [105162.160933] Modules linked in: ath12k(O) qrtr_mhi qrtr mac80211 cfg80211 mhi qmi_helpers libarc4 nvme nvme_core [last unloaded: ath12k(O)]<br /> [105162.160967] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G W O 6.1.0-rc2+ #3<br /> [105162.160972] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0056.2019.0506.1527 05/06/2019<br /> [105162.160977] RIP: 0010:ath12k_peer_find_by_id+0x52/0x60 [ath12k]<br /> [105162.160990] Code: 07 eb 0f 39 68 24 74 0a 48 8b 00 48 39 f8 75 f3 31 c0 5b 5d c3 48 8d bf b0 f2 00 00 be ff ff ff ff e8 22 20 c4 e2 85 c0 75 bf 0b eb bb 66 2e 0f 1f 84 00 00 00 00 00 41 54 4c 8d a7 98 f2 00<br /> [105162.160996] RSP: 0018:ffffa223001acc60 EFLAGS: 00010246<br /> [105162.161003] RAX: 0000000000000000 RBX: ffff9f0573940000 RCX: 0000000000000000<br /> [105162.161008] RDX: 0000000000000001 RSI: ffffffffa3951c8e RDI: ffffffffa39a96d7<br /> [105162.161013] RBP: 000000000000000a R08: 0000000000000000 R09: 0000000000000000<br /> [105162.161017] R10: ffffa223001acb40 R11: ffffffffa3d57c60 R12: ffff9f057394f2e0<br /> [105162.161022] R13: ffff9f0573940000 R14: ffff9f04ecd659c0 R15: ffff9f04d5a9b040<br /> [105162.161026] FS: 0000000000000000(0000) GS:ffff9f0575600000(0000) knlGS:0000000000000000<br /> [105162.161031] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [105162.161036] CR2: 00001d5c8277a008 CR3: 00000001e6224006 CR4: 00000000003706e0<br /> [105162.161041] Call Trace:<br /> [105162.161046] <br /> [105162.161051] ath12k_dp_rx_process_wbm_err+0x6da/0xaf0 [ath12k]<br /> [105162.161072] ? ath12k_dp_rx_process_err+0x80e/0x15a0 [ath12k]<br /> [105162.161084] ? __lock_acquire+0x4ca/0x1a60<br /> [105162.161104] ath12k_dp_service_srng+0x263/0x310 [ath12k]<br /> [105162.161120] ath12k_pci_ext_grp_napi_poll+0x1c/0x70 [ath12k]<br /> [105162.161133] __napi_poll+0x22/0x260<br /> [105162.161141] net_rx_action+0x2f8/0x380<br /> [105162.161153] __do_softirq+0xd0/0x4c9<br /> [105162.161162] irq_exit_rcu+0x88/0xe0<br /> [105162.161169] common_interrupt+0xa5/0xc0<br /> [105162.161174] <br /> [105162.161179] <br /> [105162.161184] asm_common_interrupt+0x22/0x40<br /> <br /> Handle spin lock/unlock in WBM error path to hold the necessary lock<br /> expected by ath12k_peer_find_by_id().<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0-03171-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: free background tracker&amp;#39;s queued work in btracker_destroy<br /> <br /> Otherwise the kernel can BUG with:<br /> <br /> [ 2245.426978] =============================================================================<br /> [ 2245.435155] BUG bt_work (Tainted: G B W ): Objects remaining in bt_work on __kmem_cache_shutdown()<br /> [ 2245.445233] -----------------------------------------------------------------------------<br /> [ 2245.445233]<br /> [ 2245.454879] Slab 0x00000000b0ce2b30 objects=64 used=2 fp=0x000000000a3c6a4e flags=0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)<br /> [ 2245.467300] CPU: 7 PID: 10805 Comm: lvm Kdump: loaded Tainted: G B W 6.0.0-rc2 #19<br /> [ 2245.476078] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.5.6 10/06/2021<br /> [ 2245.483646] Call Trace:<br /> [ 2245.486100] <br /> [ 2245.488206] dump_stack_lvl+0x34/0x48<br /> [ 2245.491878] slab_err+0x95/0xcd<br /> [ 2245.495028] __kmem_cache_shutdown.cold+0x31/0x136<br /> [ 2245.499821] kmem_cache_destroy+0x49/0x130<br /> [ 2245.503928] btracker_destroy+0x12/0x20 [dm_cache]<br /> [ 2245.508728] smq_destroy+0x15/0x60 [dm_cache_smq]<br /> [ 2245.513435] dm_cache_policy_destroy+0x12/0x20 [dm_cache]<br /> [ 2245.518834] destroy+0xc0/0x110 [dm_cache]<br /> [ 2245.522933] dm_table_destroy+0x5c/0x120 [dm_mod]<br /> [ 2245.527649] __dm_destroy+0x10e/0x1c0 [dm_mod]<br /> [ 2245.532102] dev_remove+0x117/0x190 [dm_mod]<br /> [ 2245.536384] ctl_ioctl+0x1a2/0x290 [dm_mod]<br /> [ 2245.540579] dm_ctl_ioctl+0xa/0x20 [dm_mod]<br /> [ 2245.544773] __x64_sys_ioctl+0x8a/0xc0<br /> [ 2245.548524] do_syscall_64+0x5c/0x90<br /> [ 2245.552104] ? syscall_exit_to_user_mode+0x12/0x30<br /> [ 2245.556897] ? do_syscall_64+0x69/0x90<br /> [ 2245.560648] ? do_syscall_64+0x69/0x90<br /> [ 2245.564394] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 2245.569447] RIP: 0033:0x7fe52583ec6b<br /> ...<br /> [ 2245.646771] ------------[ cut here ]------------<br /> [ 2245.651395] kmem_cache_destroy bt_work: Slab cache still has objects when called from btracker_destroy+0x12/0x20 [dm_cache]<br /> [ 2245.651408] WARNING: CPU: 7 PID: 10805 at mm/slab_common.c:478 kmem_cache_destroy+0x128/0x130<br /> <br /> Found using: lvm2-testsuite --only "cache-single-split.sh"<br /> <br /> Ben bisected and found that commit 0495e337b703 ("mm/slab_common:<br /> Deleting kobject in kmem_cache_destroy() without holding<br /> slab_mutex/cpu_hotplug_lock") first exposed dm-cache&amp;#39;s incomplete<br /> cleanup of its background tracker work objects.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> FS: JFS: Check for read-only mounted filesystem in txBegin<br /> <br /> This patch adds a check for read-only mounted filesystem<br /> in txBegin before starting a transaction potentially saving<br /> from NULL pointer deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix memory leak in ath12k_qmi_driver_event_work()<br /> <br /> Currently the buffer pointed by event is not freed in case<br /> ATH12K_FLAG_UNREGISTERING bit is set, this causes memory leak.<br /> <br /> Add a goto skip instead of return, to ensure event and all the<br /> list entries are freed properly.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap-irq: Fix out-of-bounds access when allocating config buffers<br /> <br /> When allocating the 2D array for handling IRQ type registers in<br /> regmap_add_irq_chip_fwnode(), the intent is to allocate a matrix<br /> with num_config_bases rows and num_config_regs columns.<br /> <br /> This is currently handled by allocating a buffer to hold a pointer for<br /> each row (i.e. num_config_bases). After that, the logic attempts to<br /> allocate the memory required to hold the register configuration for<br /> each row. However, instead of doing this allocation for each row<br /> (i.e. num_config_bases allocations), the logic erroneously does this<br /> allocation num_config_regs number of times.<br /> <br /> This scenario can lead to out-of-bounds accesses when num_config_regs<br /> is greater than num_config_bases. Fix this by updating the terminating<br /> condition of the loop that allocates the memory for holding the register<br /> configuration to allocate memory only for each row in the matrix.<br /> <br /> Amit Pundir reported a crash that was occurring on his db845c device<br /> due to memory corruption (see "Closes" tag for Amit&amp;#39;s report). The KASAN<br /> report below helped narrow it down to this issue:<br /> <br /> [ 14.033877][ T1] ==================================================================<br /> [ 14.042507][ T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364<br /> [ 14.050796][ T1] Write of size 8 at addr 06ffff8081021850 by task init/1<br /> <br /> [ 14.242004][ T1] The buggy address belongs to the object at ffffff8081021850<br /> [ 14.242004][ T1] which belongs to the cache kmalloc-8 of size 8<br /> [ 14.255669][ T1] The buggy address is located 0 bytes inside of<br /> [ 14.255669][ T1] 8-byte region [ffffff8081021850, ffffff8081021858)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virt/coco/sev-guest: Double-buffer messages<br /> <br /> The encryption algorithms read and write directly to shared unencrypted<br /> memory, which may leak information as well as permit the host to tamper<br /> with the message integrity. Instead, copy whole messages in or out as<br /> needed before doing any computation on them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ptdma: check for null desc before calling pt_cmd_callback<br /> <br /> Resolves a panic that can occur on AMD systems, typically during host<br /> shutdown, after the PTDMA driver had been exercised. The issue was<br /> the pt_issue_pending() function is mistakenly assuming that there will<br /> be at least one descriptor in the Submitted queue when the function<br /> is called. However, it is possible that both the Submitted and Issued<br /> queues could be empty, which could result in pt_cmd_callback() being<br /> mistakenly called with a NULL pointer.<br /> Ref: Bugzilla Bug 216856.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Fix crash due to uninitialized current_vmcs<br /> <br /> KVM enables &amp;#39;Enlightened VMCS&amp;#39; and &amp;#39;Enlightened MSR Bitmap&amp;#39; when running as<br /> a nested hypervisor on top of Hyper-V. When MSR bitmap is updated,<br /> evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to mark<br /> that the msr bitmap was changed.<br /> <br /> vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr<br /> -&gt; vmx_msr_bitmap_l01_changed which in the end calls this function. The<br /> function checks for current_vmcs if it is null but the check is<br /> insufficient because current_vmcs is not initialized. Because of this, the<br /> code might incorrectly write to the structure pointed by current_vmcs value<br /> left by another task. Preemption is not disabled, the current task can be<br /> preempted and moved to another CPU while current_vmcs is accessed multiple<br /> times from evmcs_touch_msr_bitmap() which leads to crash.<br /> <br /> The manipulation of MSR bitmaps by callers happens only for vmcs01 so the<br /> solution is to use vmx-&gt;vmcs01.vmcs instead of current_vmcs.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000338<br /> PGD 4e1775067 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> ...<br /> RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel]<br /> ...<br /> Call Trace:<br /> vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel]<br /> vmx_vcpu_create+0xe6/0x540 [kvm_intel]<br /> kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm]<br /> kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm]<br /> kvm_vm_ioctl+0x53f/0x790 [kvm]<br /> __x64_sys_ioctl+0x8a/0xc0<br /> do_syscall_64+0x5c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: atmel-quadspi: Free resources even if runtime resume failed in .remove()<br /> <br /> An early error exit in atmel_qspi_remove() doesn&amp;#39;t prevent the device<br /> unbind. So this results in an spi controller with an unbound parent<br /> and unmapped register space (because devm_ioremap_resource() is undone).<br /> So using the remaining spi controller probably results in an oops.<br /> <br /> Instead unregister the controller unconditionally and only skip hardware<br /> access and clk disable.<br /> <br /> Also add a warning about resume failing and return zero unconditionally.<br /> The latter has the only effect to suppress a less helpful error message by<br /> the spi core.