Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix DMA mappings leak<br /> <br /> During reallocation of RX buffers, new DMA mappings are created for<br /> those buffers.<br /> <br /> steps for reproduction:<br /> while :<br /> do<br /> for ((i=0; i

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_vti: fix slab-use-after-free in decode_session6<br /> <br /> When ipv6_vti device is set to the qdisc of the sfb type, the cb field<br /> of the sent skb may be modified during enqueuing. Then,<br /> slab-use-after-free may occur when ipv6_vti device sends IPv6 packets.<br /> <br /> The stack information is as follows:<br /> BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890<br /> Read of size 1 at addr ffff88802e08edc2 by task swapper/0/0<br /> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xd9/0x150<br /> print_address_description.constprop.0+0x2c/0x3c0<br /> kasan_report+0x11d/0x130<br /> decode_session6+0x103f/0x1890<br /> __xfrm_decode_session+0x54/0xb0<br /> vti6_tnl_xmit+0x3e6/0x1ee0<br /> dev_hard_start_xmit+0x187/0x700<br /> sch_direct_xmit+0x1a3/0xc30<br /> __qdisc_run+0x510/0x17a0<br /> __dev_queue_xmit+0x2215/0x3b10<br /> neigh_connected_output+0x3c2/0x550<br /> ip6_finish_output2+0x55a/0x1550<br /> ip6_finish_output+0x6b9/0x1270<br /> ip6_output+0x1f1/0x540<br /> ndisc_send_skb+0xa63/0x1890<br /> ndisc_send_rs+0x132/0x6f0<br /> addrconf_rs_timer+0x3f1/0x870<br /> call_timer_fn+0x1a0/0x580<br /> expire_timers+0x29b/0x4b0<br /> run_timer_softirq+0x326/0x910<br /> __do_softirq+0x1d4/0x905<br /> irq_exit_rcu+0xb7/0x120<br /> sysvec_apic_timer_interrupt+0x97/0xc0<br /> <br /> Allocated by task 9176:<br /> kasan_save_stack+0x22/0x40<br /> kasan_set_track+0x25/0x30<br /> __kasan_slab_alloc+0x7f/0x90<br /> kmem_cache_alloc_node+0x1cd/0x410<br /> kmalloc_reserve+0x165/0x270<br /> __alloc_skb+0x129/0x330<br /> netlink_sendmsg+0x9b1/0xe30<br /> sock_sendmsg+0xde/0x190<br /> ____sys_sendmsg+0x739/0x920<br /> ___sys_sendmsg+0x110/0x1b0<br /> __sys_sendmsg+0xf7/0x1c0<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> Freed by task 9176:<br /> kasan_save_stack+0x22/0x40<br /> kasan_set_track+0x25/0x30<br /> kasan_save_free_info+0x2b/0x40<br /> ____kasan_slab_free+0x160/0x1c0<br /> slab_free_freelist_hook+0x11b/0x220<br /> kmem_cache_free+0xf0/0x490<br /> skb_free_head+0x17f/0x1b0<br /> skb_release_data+0x59c/0x850<br /> consume_skb+0xd2/0x170<br /> netlink_unicast+0x54f/0x7f0<br /> netlink_sendmsg+0x926/0xe30<br /> sock_sendmsg+0xde/0x190<br /> ____sys_sendmsg+0x739/0x920<br /> ___sys_sendmsg+0x110/0x1b0<br /> __sys_sendmsg+0xf7/0x1c0<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> The buggy address belongs to the object at ffff88802e08ed00<br /> which belongs to the cache skbuff_small_head of size 640<br /> The buggy address is located 194 bytes inside of<br /> freed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)<br /> <br /> As commit f855691975bb ("xfrm6: Fix the nexthdr offset in<br /> _decode_session6.") showed, xfrm_decode_session was originally intended<br /> only for the receive path. IP6CB(skb)-&gt;nhoff is not set during<br /> transmission. Therefore, set the cb field in the skb to 0 before<br /> sending packets.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: Ignore frags from uninitialized peer in dp.<br /> <br /> When max virtual ap interfaces are configured in all the bands with<br /> ACS and hostapd restart is done every 60s, a crash is observed at<br /> random times.<br /> In this certain scenario, a fragmented packet is received for<br /> self peer, for which rx_tid and rx_frags are not initialized in<br /> datapath. While handling this fragment, crash is observed as the<br /> rx_frag list is uninitialised and when we walk in<br /> ath11k_dp_rx_h_sort_frags, skb null leads to exception.<br /> <br /> To address this, before processing received fragments we check<br /> dp_setup_done flag is set to ensure that peer has completed its<br /> dp peer setup for fragment queue, else ignore processing the<br /> fragments.<br /> <br /> Call trace:<br /> ath11k_dp_process_rx_err+0x550/0x1084 [ath11k]<br /> ath11k_dp_service_srng+0x70/0x370 [ath11k]<br /> 0xffffffc009693a04<br /> __napi_poll+0x30/0xa4<br /> net_rx_action+0x118/0x270<br /> __do_softirq+0x10c/0x244<br /> irq_exit+0x64/0xb4<br /> __handle_domain_irq+0x88/0xac<br /> gic_handle_irq+0x74/0xbc<br /> el1_irq+0xf0/0x1c0<br /> arch_cpu_idle+0x10/0x18<br /> do_idle+0x104/0x248<br /> cpu_startup_entry+0x20/0x64<br /> rest_init+0xd0/0xdc<br /> arch_call_rest_init+0xc/0x14<br /> start_kernel+0x480/0x4b8<br /> Code: f9400281 f94066a2 91405021 b94a0023 (f9406401)<br /> <br /> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: omap_hsmmc: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> it will lead two issues:<br /> 1. The memory that allocated in mmc_alloc_host() is leaked.<br /> 2. In the remove() path, mmc_remove_host() will be called to<br /> delete device, but it&amp;#39;s not added yet, it will lead a kernel<br /> crash because of null-ptr-deref in device_del().<br /> <br /> Fix this by checking the return value and goto error path wihch<br /> will call mmc_free_host().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix "kernel NULL pointer dereference" error<br /> <br /> When rxe_queue_init in the function rxe_qp_init_req fails,<br /> both qp-&gt;req.task.func and qp-&gt;req.task.arg are not initialized.<br /> <br /> Because of creation of qp fails, the function rxe_create_qp will<br /> call rxe_qp_do_cleanup to handle allocated resource.<br /> <br /> Before calling __rxe_do_task, both qp-&gt;req.task.func and<br /> qp-&gt;req.task.arg should be checked.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: zynq-ipi: fix error handling while device_register() fails<br /> <br /> If device_register() fails, it has two issues:<br /> 1. The name allocated by dev_set_name() is leaked.<br /> 2. The parent of device is not NULL, device_unregister() is called<br /> in zynqmp_ipi_free_mboxes(), it will lead a kernel crash because<br /> of removing not added device.<br /> <br /> Call put_device() to give up the reference, so the name is freed in<br /> kobject_cleanup(). Add device registered check in zynqmp_ipi_free_mboxes()<br /> to avoid null-ptr-deref.

*** 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.