Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().<br /> <br /> syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720<br /> ("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it by<br /> updating kcm_tx_msg(head)-&gt;last_skb if partial data is copied so that the<br /> following sendmsg() will resume from the skb.<br /> <br /> However, we cannot know how many bytes were copied when we get the error.<br /> Thus, we could mess up the MSG_MORE queue.<br /> <br /> When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as we<br /> do so for UDP by udp_flush_pending_frames().<br /> <br /> Even without this change, when the error occurred, the following sendmsg()<br /> resumed from a wrong skb and the queue was messed up. However, we have<br /> yet to get such a report, and only syzkaller stumbled on it. So, this<br /> can be changed safely.<br /> <br /> Note this does not change SOCK_SEQPACKET behaviour.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: Fix UAF wear-leveling entry in eraseblk_count_seq_show()<br /> <br /> Wear-leveling entry could be freed in error path, which may be accessed<br /> again in eraseblk_count_seq_show(), for example:<br /> <br /> __erase_worker eraseblk_count_seq_show<br /> wl = ubi-&gt;lookuptbl[*block_number]<br /> if (wl)<br /> wl_entry_destroy<br /> ubi-&gt;lookuptbl[e-&gt;pnum] = NULL<br /> kmem_cache_free(ubi_wl_entry_slab, e)<br /> erase_count = wl-&gt;ec // UAF!<br /> <br /> Wear-leveling entry updating/accessing in ubi-&gt;lookuptbl should be<br /> protected by ubi-&gt;wl_lock, fix it by adding ubi-&gt;wl_lock to serialize<br /> wl entry accessing between wl_entry_destroy() and<br /> eraseblk_count_seq_show().<br /> <br /> Fetch a reproducer in [Link].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix use-after-free in l2cap_disconnect_{req,rsp}<br /> <br /> Similar to commit d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free<br /> caused by l2cap_chan_put"), just use l2cap_chan_hold_unless_zero to<br /> prevent referencing a channel that is about to be destroyed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()<br /> <br /> KSAN reports use-after-free in hci_add_adv_monitor().<br /> <br /> While adding an adv monitor,<br /> hci_add_adv_monitor() calls -&gt;<br /> msft_add_monitor_pattern() calls -&gt;<br /> msft_add_monitor_sync() calls -&gt;<br /> msft_le_monitor_advertisement_cb() calls in an error case -&gt;<br /> hci_free_adv_monitor() which frees the *moniter.<br /> <br /> This is referenced by bt_dev_dbg() in hci_add_adv_monitor().<br /> <br /> Fix the bt_dev_dbg() by using handle instead of monitor-&gt;handle.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: flush inode if atomic file is aborted<br /> <br /> Let&amp;#39;s flush the inode being aborted atomic operation to avoid stale dirty<br /> inode during eviction in this call stack:<br /> <br /> f2fs_mark_inode_dirty_sync+0x22/0x40 [f2fs]<br /> f2fs_abort_atomic_write+0xc4/0xf0 [f2fs]<br /> f2fs_evict_inode+0x3f/0x690 [f2fs]<br /> ? sugov_start+0x140/0x140<br /> evict+0xc3/0x1c0<br /> evict_inodes+0x17b/0x210<br /> generic_shutdown_super+0x32/0x120<br /> kill_block_super+0x21/0x50<br /> deactivate_locked_super+0x31/0x90<br /> cleanup_mnt+0x100/0x160<br /> task_work_run+0x59/0x90<br /> do_exit+0x33b/0xa50<br /> do_group_exit+0x2d/0x80<br /> __x64_sys_exit_group+0x14/0x20<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> This triggers f2fs_bug_on() in f2fs_evict_inode:<br /> f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE));<br /> <br /> This fixes the syzbot report:<br /> <br /> loop0: detected capacity change from 0 to 131072<br /> F2FS-fs (loop0): invalid crc value<br /> F2FS-fs (loop0): Found nat_bits in checkpoint<br /> F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/inode.c:869!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 5014 Comm: syz-executor220 Not tainted 6.4.0-syzkaller-11479-g6cd06ab12d1a #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023<br /> RIP: 0010:f2fs_evict_inode+0x172d/0x1e00 fs/f2fs/inode.c:869<br /> Code: ff df 48 c1 ea 03 80 3c 02 00 0f 85 6a 06 00 00 8b 75 40 ba 01 00 00 00 4c 89 e7 e8 6d ce 06 00 e9 aa fc ff ff e8 63 22 e2 fd 0b e8 5c 22 e2 fd 48 c7 c0 a8 3a 18 8d 48 ba 00 00 00 00 00 fc<br /> RSP: 0018:ffffc90003a6fa00 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: ffff8880273b8000 RSI: ffffffff83a2bd0d RDI: 0000000000000007<br /> RBP: ffff888077db91b0 R08: 0000000000000007 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff888029a3c000<br /> R13: ffff888077db9660 R14: ffff888029a3c0b8 R15: ffff888077db9c50<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1909bb9000 CR3: 00000000276a9000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> evict+0x2ed/0x6b0 fs/inode.c:665<br /> dispose_list+0x117/0x1e0 fs/inode.c:698<br /> evict_inodes+0x345/0x440 fs/inode.c:748<br /> generic_shutdown_super+0xaf/0x480 fs/super.c:478<br /> kill_block_super+0x64/0xb0 fs/super.c:1417<br /> kill_f2fs_super+0x2af/0x3c0 fs/f2fs/super.c:4704<br /> deactivate_locked_super+0x98/0x160 fs/super.c:330<br /> deactivate_super+0xb1/0xd0 fs/super.c:361<br /> cleanup_mnt+0x2ae/0x3d0 fs/namespace.c:1254<br /> task_work_run+0x16f/0x270 kernel/task_work.c:179<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0xa9a/0x29a0 kernel/exit.c:874<br /> do_group_exit+0xd4/0x2a0 kernel/exit.c:1024<br /> __do_sys_exit_group kernel/exit.c:1035 [inline]<br /> __se_sys_exit_group kernel/exit.c:1033 [inline]<br /> __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1033<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f309be71a09<br /> Code: Unable to access opcode bytes at 0x7f309be719df.<br /> RSP: 002b:00007fff171df518 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 00007f309bef7330 RCX: 00007f309be71a09<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001<br /> RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 00007f309bef1e40<br /> R10: 0000000000010600 R11: 0000000000000246 R12: 00007f309bef7330<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:f2fs_evict_inode+0x172d/0x1e00 fs/f2fs/inode.c:869<br /> Code: ff df 48 c1 ea 03 80 3c 02 00 0f 85 6a 06 00 00 8b 75 40 ba 01 00 00 00 4c 89 e7 e8 6d ce 06 00 e9 aa fc ff ff e8 63 22 e2 fd 0b e8 5c 22 e2 fd 48 c7 c0 a8 3a 18 8d 48 ba 00 00 00 00 00 fc<br /> RSP: 0018:ffffc90003a6fa00 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 0000000000<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: think-lmi: Fix memory leak when showing current settings<br /> <br /> When retriving a item string with tlmi_setting(), the result has to be<br /> freed using kfree(). In current_value_show() however, malformed<br /> item strings are not freed, causing a memory leak.<br /> Fix this by eliminating the early return responsible for this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> loop: loop_set_status_from_info() check before assignment<br /> <br /> In loop_set_status_from_info(), lo-&gt;lo_offset and lo-&gt;lo_sizelimit should<br /> be checked before reassignment, because if an overflow error occurs, the<br /> original correct value will be changed to the wrong value, and it will not<br /> be changed back.<br /> <br /> More, the original patch did not solve the problem, the value was set and<br /> ioctl returned an error, but the subsequent io used the value in the loop<br /> driver, which still caused an alarm:<br /> <br /> loop_handle_cmd<br /> do_req_filebacked<br /> loff_t pos = ((loff_t) blk_rq_pos(rq) iocb.ki_pos = pos

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix invalid address access when enabling SCAN log level<br /> <br /> The variable i is changed when setting random MAC address and causes<br /> invalid address access when printing the value of pi-&gt;reqs[i]-&gt;reqid.<br /> <br /> We replace reqs index with ri to fix the issue.<br /> <br /> [ 136.726473] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000<br /> [ 136.737365] Mem abort info:<br /> [ 136.740172] ESR = 0x96000004<br /> [ 136.743359] Exception class = DABT (current EL), IL = 32 bits<br /> [ 136.749294] SET = 0, FnV = 0<br /> [ 136.752481] EA = 0, S1PTW = 0<br /> [ 136.755635] Data abort info:<br /> [ 136.758514] ISV = 0, ISS = 0x00000004<br /> [ 136.762487] CM = 0, WnR = 0<br /> [ 136.765522] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000005c4e2577<br /> [ 136.772265] [0000000000000000] pgd=0000000000000000<br /> [ 136.777160] Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> [ 136.782732] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) compat(O)<br /> [ 136.789788] Process wificond (pid: 3175, stack limit = 0x00000000053048fb)<br /> [ 136.796664] CPU: 3 PID: 3175 Comm: wificond Tainted: G O 4.19.42-00001-g531a5f5 #1<br /> [ 136.805532] Hardware name: Freescale i.MX8MQ EVK (DT)<br /> [ 136.810584] pstate: 60400005 (nZCv daif +PAN -UAO)<br /> [ 136.815429] pc : brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac]<br /> [ 136.821811] lr : brcmf_pno_config_sched_scans+0x67c/0xa80 [brcmfmac]<br /> [ 136.828162] sp : ffff00000e9a3880<br /> [ 136.831475] x29: ffff00000e9a3890 x28: ffff800020543400<br /> [ 136.836786] x27: ffff8000b1008880 x26: ffff0000012bf6a0<br /> [ 136.842098] x25: ffff80002054345c x24: ffff800088d22400<br /> [ 136.847409] x23: ffff0000012bf638 x22: ffff0000012bf6d8<br /> [ 136.852721] x21: ffff8000aced8fc0 x20: ffff8000ac164400<br /> [ 136.858032] x19: ffff00000e9a3946 x18: 0000000000000000<br /> [ 136.863343] x17: 0000000000000000 x16: 0000000000000000<br /> [ 136.868655] x15: ffff0000093f3b37 x14: 0000000000000050<br /> [ 136.873966] x13: 0000000000003135 x12: 0000000000000000<br /> [ 136.879277] x11: 0000000000000000 x10: ffff000009a61888<br /> [ 136.884589] x9 : 000000000000000f x8 : 0000000000000008<br /> [ 136.889900] x7 : 303a32303d726464 x6 : ffff00000a1f957d<br /> [ 136.895211] x5 : 0000000000000000 x4 : ffff00000e9a3942<br /> [ 136.900523] x3 : 0000000000000000 x2 : ffff0000012cead8<br /> [ 136.905834] x1 : ffff0000012bf6d8 x0 : 0000000000000000<br /> [ 136.911146] Call trace:<br /> [ 136.913623] brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac]<br /> [ 136.919658] brcmf_pno_start_sched_scan+0xa4/0x118 [brcmfmac]<br /> [ 136.925430] brcmf_cfg80211_sched_scan_start+0x80/0xe0 [brcmfmac]<br /> [ 136.931636] nl80211_start_sched_scan+0x140/0x308 [cfg80211]<br /> [ 136.937298] genl_rcv_msg+0x358/0x3f4<br /> [ 136.940960] netlink_rcv_skb+0xb4/0x118<br /> [ 136.944795] genl_rcv+0x34/0x48<br /> [ 136.947935] netlink_unicast+0x264/0x300<br /> [ 136.951856] netlink_sendmsg+0x2e4/0x33c<br /> [ 136.955781] __sys_sendto+0x120/0x19c

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