Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix use-after-free in ext4_orphan_cleanup<br /> <br /> I caught a issue as follows:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in __list_add_valid+0x28/0x1a0<br /> Read of size 8 at addr ffff88814b13f378 by task mount/710<br /> <br /> CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x73/0x9f<br /> print_report+0x25d/0x759<br /> kasan_report+0xc0/0x120<br /> __asan_load8+0x99/0x140<br /> __list_add_valid+0x28/0x1a0<br /> ext4_orphan_cleanup+0x564/0x9d0 [ext4]<br /> __ext4_fill_super+0x48e2/0x5300 [ext4]<br /> ext4_fill_super+0x19f/0x3a0 [ext4]<br /> get_tree_bdev+0x27b/0x450<br /> ext4_get_tree+0x19/0x30 [ext4]<br /> vfs_get_tree+0x49/0x150<br /> path_mount+0xaae/0x1350<br /> do_mount+0xe2/0x110<br /> __x64_sys_mount+0xf0/0x190<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [...]<br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> -------------------------------------<br /> ext4_fill_super<br /> ext4_orphan_cleanup<br /> --- loop1: assume last_orphan is 12 ---<br /> list_add(&amp;EXT4_I(inode)-&gt;i_orphan, &amp;EXT4_SB(sb)-&gt;s_orphan)<br /> ext4_truncate --&gt; return 0<br /> ext4_inode_attach_jinode --&gt; return -ENOMEM<br /> iput(inode) --&gt; free inode<br /> --- loop2: last_orphan is still 12 ---<br /> list_add(&amp;EXT4_I(inode)-&gt;i_orphan, &amp;EXT4_SB(sb)-&gt;s_orphan);<br /> // use inode and trigger UAF<br /> <br /> To solve this issue, we need to propagate the return value of<br /> ext4_inode_attach_jinode() appropriately.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: vdso: fix NULL deference in vdso_join_timens() when vfork<br /> <br /> Testing tools/testing/selftests/timens/vfork_exec.c got below<br /> kernel log:<br /> <br /> [ 6.838454] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000020<br /> [ 6.842255] Oops [#1]<br /> [ 6.842871] Modules linked in:<br /> [ 6.844249] CPU: 1 PID: 64 Comm: vfork_exec Not tainted 6.0.0-rc3-rt15+ #8<br /> [ 6.845861] Hardware name: riscv-virtio,qemu (DT)<br /> [ 6.848009] epc : vdso_join_timens+0xd2/0x110<br /> [ 6.850097] ra : vdso_join_timens+0xd2/0x110<br /> [ 6.851164] epc : ffffffff8000635c ra : ffffffff8000635c sp : ff6000000181fbf0<br /> [ 6.852562] gp : ffffffff80cff648 tp : ff60000000fdb700 t0 : 3030303030303030<br /> [ 6.853852] t1 : 0000000000000030 t2 : 3030303030303030 s0 : ff6000000181fc40<br /> [ 6.854984] s1 : ff60000001e6c000 a0 : 0000000000000010 a1 : ffffffff8005654c<br /> [ 6.856221] a2 : 00000000ffffefff a3 : 0000000000000000 a4 : 0000000000000000<br /> [ 6.858114] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038<br /> [ 6.859484] s2 : ff60000001e6c068 s3 : ff6000000108abb0 s4 : 0000000000000000<br /> [ 6.860751] s5 : 0000000000001000 s6 : ffffffff8089dc40 s7 : ffffffff8089dc38<br /> [ 6.862029] s8 : ffffffff8089dc30 s9 : ff60000000fdbe38 s10: 000000000000005e<br /> [ 6.863304] s11: ffffffff80cc3510 t3 : ffffffff80d1112f t4 : ffffffff80d1112f<br /> [ 6.864565] t5 : ffffffff80d11130 t6 : ff6000000181fa00<br /> [ 6.865561] status: 0000000000000120 badaddr: 0000000000000020 cause: 000000000000000d<br /> [ 6.868046] [] timens_commit+0x38/0x11a<br /> [ 6.869089] [] timens_on_fork+0x72/0xb4<br /> [ 6.870055] [] begin_new_exec+0x3c6/0x9f0<br /> [ 6.871231] [] load_elf_binary+0x628/0x1214<br /> [ 6.872304] [] bprm_execve+0x1f2/0x4e4<br /> [ 6.873243] [] do_execveat_common+0x16e/0x1ee<br /> [ 6.874258] [] sys_execve+0x3c/0x48<br /> [ 6.875162] [] ret_from_syscall+0x0/0x2<br /> [ 6.877484] ---[ end trace 0000000000000000 ]---<br /> <br /> This is because the mm-&gt;context.vdso_info is NULL in vfork case. From<br /> another side, mm-&gt;context.vdso_info either points to vdso info<br /> for RV64 or vdso info for compat, there&amp;#39;s no need to bloat riscv&amp;#39;s<br /> mm_context_t, we can handle the difference when setup the additional<br /> page for vdso.

*** Pendiente de traducción *** 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()).

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

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

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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").