Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mte: Avoid setting PG_mte_tagged if no tags cleared or restored<br /> <br /> Prior to commit 69e3b846d8a7 ("arm64: mte: Sync tags for pages where PTE<br /> is untagged"), mte_sync_tags() was only called for pte_tagged() entries<br /> (those mapped with PROT_MTE). Therefore mte_sync_tags() could safely use<br /> test_and_set_bit(PG_mte_tagged, &amp;page-&gt;flags) without inadvertently<br /> setting PG_mte_tagged on an untagged page.<br /> <br /> The above commit was required as guests may enable MTE without any<br /> control at the stage 2 mapping, nor a PROT_MTE mapping in the VMM.<br /> However, the side-effect was that any page with a PTE that looked like<br /> swap (or migration) was getting PG_mte_tagged set automatically. A<br /> subsequent page copy (e.g. migration) copied the tags to the destination<br /> page even if the tags were owned by KASAN.<br /> <br /> This issue was masked by the page_kasan_tag_reset() call introduced in<br /> commit e5b8d9218951 ("arm64: mte: reset the page tag in page-&gt;flags").<br /> When this commit was reverted (20794545c146), KASAN started reporting<br /> access faults because the overriding tags in a page did not match the<br /> original page-&gt;flags (with CONFIG_KASAN_HW_TAGS=y):<br /> <br /> BUG: KASAN: invalid-access in copy_page+0x10/0xd0 arch/arm64/lib/copy_page.S:26<br /> Read at addr f5ff000017f2e000 by task syz-executor.1/2218<br /> Pointer tag: [f5], memory tag: [f2]<br /> <br /> Move the PG_mte_tagged bit setting from mte_sync_tags() to the actual<br /> place where tags are cleared (mte_sync_page_tags()) or restored<br /> (mte_restore_tags()).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rds: don&amp;#39;t hold sock lock when cancelling work from rds_tcp_reset_callbacks()<br /> <br /> syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], for<br /> commit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in<br /> rds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a section<br /> protected by lock_sock() without realizing that rds_send_xmit() might call<br /> lock_sock().<br /> <br /> We don&amp;#39;t need to protect cancel_delayed_work_sync() using lock_sock(), for<br /> even if rds_{send,recv}_worker() re-queued this work while __flush_work()<br /> from cancel_delayed_work_sync() was waiting for this work to complete,<br /> retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UP<br /> bit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: fix use after free in _ipmi_destroy_user()<br /> <br /> The intf_free() function frees the "intf" pointer so we cannot<br /> dereference it again on the next line.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: fix memory leak in hns_roce_alloc_mr()<br /> <br /> When hns_roce_mr_enable() failed in hns_roce_alloc_mr(), mr_key is not<br /> released. Compiled test only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix possible memory leak in stmmac_dvr_probe()<br /> <br /> The bitmap_free() should be called to free priv-&gt;af_xdp_zc_qps<br /> when create_singlethread_workqueue() fails, otherwise there will<br /> be a memory leak, so we add the err path error_wq_init to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-frontends: fix leak of memory fw

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix failed to find the peer with peer_id 0 when disconnected<br /> <br /> It has a fail log which is ath11k_dbg in ath11k_dp_rx_process_mon_status(),<br /> as below, it will not print when debug_mask is not set ATH11K_DBG_DATA.<br /> ath11k_dbg(ab, ATH11K_DBG_DATA,<br /> "failed to find the peer with peer_id %d\n",<br /> ppdu_info.peer_id);<br /> <br /> When run scan with station disconnected, the peer_id is 0 for case<br /> HAL_RX_MPDU_START in ath11k_hal_rx_parse_mon_status_tlv() which called<br /> from ath11k_dp_rx_process_mon_status(), and the peer_id of ppdu_info is<br /> reset to 0 in the while loop, so it does not match condition of the<br /> check "if (ppdu_info-&gt;peer_id == HAL_INVALID_PEERID" in the loop, and<br /> then the log "failed to find the peer with peer_id 0" print after the<br /> check in the loop, it is below call stack when debug_mask is set<br /> ATH11K_DBG_DATA.<br /> <br /> The reason is this commit 01d2f285e3e5 ("ath11k: decode HE status tlv")<br /> add "memset(ppdu_info, 0, sizeof(struct hal_rx_mon_ppdu_info))" in<br /> ath11k_dp_rx_process_mon_status(), but the commit does not initialize<br /> the peer_id to HAL_INVALID_PEERID, then lead the check mis-match.<br /> <br /> Callstack of the failed log:<br /> [12335.689072] RIP: 0010:ath11k_dp_rx_process_mon_status+0x9ea/0x1020 [ath11k]<br /> [12335.689157] Code: 89 ff e8 f9 10 00 00 be 01 00 00 00 4c 89 f7 e8 dc 4b 4e de 48 8b 85 38 ff ff ff c7 80 e4 07 00 00 01 00 00 00 e9 20 f8 ff ff 0b 41 0f b7 96 be 06 00 00 48 c7 c6 b8 50 44 c1 4c 89 ff e8 fd<br /> [12335.689180] RSP: 0018:ffffb874001a4ca0 EFLAGS: 00010246<br /> [12335.689210] RAX: 0000000000000000 RBX: ffff995642cbd100 RCX: 0000000000000000<br /> [12335.689229] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff99564212cd18<br /> [12335.689248] RBP: ffffb874001a4dc0 R08: 0000000000000001 R09: 0000000000000000<br /> [12335.689268] R10: 0000000000000220 R11: ffffb874001a48e8 R12: ffff995642473d40<br /> [12335.689286] R13: ffff99564212c5b8 R14: ffff9956424736a0 R15: ffff995642120000<br /> [12335.689303] FS: 0000000000000000(0000) GS:ffff995739000000(0000) knlGS:0000000000000000<br /> [12335.689323] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [12335.689341] CR2: 00007f43c5d5e039 CR3: 000000011c012005 CR4: 00000000000606e0<br /> [12335.689360] Call Trace:<br /> [12335.689377] <br /> [12335.689418] ? rcu_read_lock_held_common+0x12/0x50<br /> [12335.689447] ? rcu_read_lock_sched_held+0x25/0x80<br /> [12335.689471] ? rcu_read_lock_held_common+0x12/0x50<br /> [12335.689504] ath11k_dp_rx_process_mon_rings+0x8d/0x4f0 [ath11k]<br /> [12335.689578] ? ath11k_dp_rx_process_mon_rings+0x8d/0x4f0 [ath11k]<br /> [12335.689653] ? lock_acquire+0xef/0x360<br /> [12335.689681] ? rcu_read_lock_sched_held+0x25/0x80<br /> [12335.689713] ath11k_dp_service_mon_ring+0x38/0x60 [ath11k]<br /> [12335.689784] ? ath11k_dp_rx_process_mon_rings+0x4f0/0x4f0 [ath11k]<br /> [12335.689860] call_timer_fn+0xb2/0x2f0<br /> [12335.689897] ? ath11k_dp_rx_process_mon_rings+0x4f0/0x4f0 [ath11k]<br /> [12335.689970] run_timer_softirq+0x21f/0x540<br /> [12335.689999] ? ktime_get+0xad/0x160<br /> [12335.690025] ? lapic_next_deadline+0x2c/0x40<br /> [12335.690053] ? clockevents_program_event+0x82/0x100<br /> [12335.690093] __do_softirq+0x151/0x4a8<br /> [12335.690135] irq_exit_rcu+0xc9/0x100<br /> [12335.690165] sysvec_apic_timer_interrupt+0xa8/0xd0<br /> [12335.690189] <br /> [12335.690204] <br /> [12335.690225] asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> <br /> Reset the default value to HAL_INVALID_PEERID each time after memset<br /> of ppdu_info as well as others memset which existed in function<br /> ath11k_dp_rx_process_mon_status(), then the failed log disappeared.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix QP destroy to wait for all references dropped.<br /> <br /> Delay QP destroy completion until all siw references to QP are<br /> dropped. The calling RDMA core will free QP structure after<br /> successful return from siw_qp_destroy() call, so siw must not<br /> hold any remaining reference to the QP upon return.<br /> A use-after-free was encountered in xfstest generic/460, while<br /> testing NFSoRDMA. Here, after a TCP connection drop by peer,<br /> the triggered siw_cm_work_handler got delayed until after<br /> QP destroy call, referencing a QP which has already freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix memory leak in vmw_mksstat_add_ioctl()<br /> <br /> If the copy of the description string from userspace fails, then the page<br /> for the instance descriptor doesn&amp;#39;t get freed before returning -EFAULT,<br /> which leads to a memleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix deadlock due to mbcache entry corruption<br /> <br /> When manipulating xattr blocks, we can deadlock infinitely looping<br /> inside ext4_xattr_block_set() where we constantly keep finding xattr<br /> block for reuse in mbcache but we are unable to reuse it because its<br /> reference count is too big. This happens because cache entry for the<br /> xattr block is marked as reusable (e_reusable set) although its<br /> reference count is too big. When this inconsistency happens, this<br /> inconsistent state is kept indefinitely and so ext4_xattr_block_set()<br /> keeps retrying indefinitely.<br /> <br /> The inconsistent state is caused by non-atomic update of e_reusable bit.<br /> e_reusable is part of a bitfield and e_reusable update can race with<br /> update of e_referenced bit in the same bitfield resulting in loss of one<br /> of the updates. Fix the problem by using atomic bitops instead.<br /> <br /> This bug has been around for many years, but it became *much* easier<br /> to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr<br /> blocks").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: ocxl: fix possible name leak in ocxl_file_register_afu()<br /> <br /> If device_register() returns error in ocxl_file_register_afu(),<br /> the name allocated by dev_set_name() need be freed. As comment<br /> of device_register() says, it should use put_device() to give<br /> up the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanup(),<br /> and info is freed in info_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: mm: add missing memcpy in kasan_init<br /> <br /> Hi Atish,<br /> <br /> It seems that the panic is due to the missing memcpy during kasan_init.<br /> Could you please check whether this patch is helpful?<br /> <br /> When doing kasan_populate, the new allocated base_pud/base_p4d should<br /> contain kasan_early_shadow_{pud, p4d}&amp;#39;s content. Add the missing memcpy<br /> to avoid page fault when read/write kasan shadow region.<br /> <br /> Tested on:<br /> - qemu with sv57 and CONFIG_KASAN on.<br /> - qemu with sv48 and CONFIG_KASAN on.