Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register()<br /> <br /> mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets<br /> some error, mhi_ctrl should be freed with mhi_free_controller(). But<br /> when ath11k_mhi_read_addr_from_dt() fails, the function returns without<br /> calling mhi_free_controller(), which will lead to a memory leak.<br /> <br /> We can fix it by calling mhi_free_controller() when<br /> ath11k_mhi_read_addr_from_dt() fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times<br /> <br /> device_add shall not be called multiple times as stated in its<br /> documentation:<br /> <br /> &amp;#39;Do not call this routine or device_register() more than once for<br /> any device structure&amp;#39;<br /> <br /> Syzkaller reports a bug as follows [1]:<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:33!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> [...]<br /> Call Trace:<br /> <br /> __list_add include/linux/list.h:69 [inline]<br /> list_add_tail include/linux/list.h:102 [inline]<br /> kobj_kset_join lib/kobject.c:164 [inline]<br /> kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214<br /> kobject_add_varg lib/kobject.c:358 [inline]<br /> kobject_add+0x150/0x1c0 lib/kobject.c:410<br /> device_add+0x368/0x1e90 drivers/base/core.c:3452<br /> hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53<br /> hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799<br /> hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110<br /> hci_event_func net/bluetooth/hci_event.c:7440 [inline]<br /> hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495<br /> hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007<br /> process_one_work+0x991/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e4/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br />

*** Pendiente de traducción *** An issue in user interface in Kyocera Command Center RX EXOSYS M5521cdn allows remote to obtain sensitive information via inspecting sent packages by user.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Protect rcu_print_task_exp_stall() -&gt;exp_tasks access<br /> <br /> For kernels built with CONFIG_PREEMPT_RCU=y, the following scenario can<br /> result in a NULL-pointer dereference:<br /> <br /> CPU1 CPU2<br /> rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall<br /> if (special.b.blocked) READ_ONCE(rnp-&gt;exp_tasks) != NULL<br /> raw_spin_lock_rcu_node<br /> np = rcu_next_node_entry(t, rnp)<br /> if (&amp;t-&gt;rcu_node_entry == rnp-&gt;exp_tasks)<br /> WRITE_ONCE(rnp-&gt;exp_tasks, np)<br /> ....<br /> raw_spin_unlock_irqrestore_rcu_node<br /> raw_spin_lock_irqsave_rcu_node<br /> t = list_entry(rnp-&gt;exp_tasks-&gt;prev,<br /> struct task_struct, rcu_node_entry)<br /> (if rnp-&gt;exp_tasks is NULL, this<br /> will dereference a NULL pointer)<br /> <br /> The problem is that CPU2 accesses the rcu_node structure&amp;#39;s-&gt;exp_tasks<br /> field without holding the rcu_node structure&amp;#39;s -&gt;lock and CPU2 did<br /> not observe CPU1&amp;#39;s change to rcu_node structure&amp;#39;s -&gt;exp_tasks in time.<br /> Therefore, if CPU1 sets rcu_node structure&amp;#39;s-&gt;exp_tasks pointer to NULL,<br /> then CPU2 might dereference that NULL pointer.<br /> <br /> This commit therefore holds the rcu_node structure&amp;#39;s -&gt;lock while<br /> accessing that structure&amp;#39;s-&gt;exp_tasks field.<br /> <br /> [ paulmck: Apply Frederic Weisbecker feedback. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: Fix panic about slab-out-of-bounds caused by ntfs_listxattr()<br /> <br /> Here is a BUG report from syzbot:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]<br /> BUG: KASAN: slab-out-of-bounds in ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710<br /> Read of size 1 at addr ffff888021acaf3d by task syz-executor128/3632<br /> <br /> Call Trace:<br /> ntfs_list_ea fs/ntfs3/xattr.c:191 [inline]<br /> ntfs_listxattr+0x401/0x570 fs/ntfs3/xattr.c:710<br /> vfs_listxattr fs/xattr.c:457 [inline]<br /> listxattr+0x293/0x2d0 fs/xattr.c:804<br /> <br /> Fix the logic of ea_all iteration. When the ea-&gt;name_len is 0,<br /> return immediately, or Add2Ptr() would visit invalid memory<br /> in the next loop.<br /> <br /> [almaz.alexandrovich@paragon-software.com: lines of the patch have changed]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()<br /> <br /> When blkg_alloc() is called to allocate a blkcg_gq structure<br /> with the associated blkg_iostat_set&amp;#39;s, there are 2 fields within<br /> blkg_iostat_set that requires proper initialization - blkg &amp; sync.<br /> The former field was introduced by commit 3b8cc6298724 ("blk-cgroup:<br /> Optimize blkcg_rstat_flush()") while the later one was introduced by<br /> commit f73316482977 ("blk-cgroup: reimplement basic IO stats using<br /> cgroup rstat").<br /> <br /> Unfortunately those fields in the blkg_iostat_set&amp;#39;s are not properly<br /> re-initialized when they are cleared in v1&amp;#39;s blkcg_reset_stats(). This<br /> can lead to a kernel panic due to NULL pointer access of the blkg<br /> pointer. The missing initialization of sync is less problematic and<br /> can be a problem in a debug kernel due to missing lockdep initialization.<br /> <br /> Fix these problems by re-initializing them after memory clearing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()<br /> <br /> &gt; ret = brcmf_proto_tx_queue_data(drvr, ifp-&gt;ifidx, skb);<br /> <br /> may be schedule, and then complete before the line<br /> <br /> &gt; ndev-&gt;stats.tx_bytes += skb-&gt;len;<br /> <br /> [ 46.912801] ==================================================================<br /> [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]<br /> [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328<br /> [ 46.935991]<br /> [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1<br /> [ 46.947255] Hardware name: [REDACTED]<br /> [ 46.954568] Call trace:<br /> [ 46.957037] dump_backtrace+0x0/0x2b8<br /> [ 46.960719] show_stack+0x24/0x30<br /> [ 46.964052] dump_stack+0x128/0x194<br /> [ 46.967557] print_address_description.isra.0+0x64/0x380<br /> [ 46.972877] __kasan_report+0x1d4/0x240<br /> [ 46.976723] kasan_report+0xc/0x18<br /> [ 46.980138] __asan_report_load4_noabort+0x18/0x20<br /> [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]<br /> [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0<br /> [ 46.994894] sch_direct_xmit+0x198/0xd08<br /> [ 46.998827] __qdisc_run+0x37c/0x1dc0<br /> [ 47.002500] __dev_queue_xmit+0x1528/0x21f8<br /> [ 47.006692] dev_queue_xmit+0x24/0x30<br /> [ 47.010366] neigh_resolve_output+0x37c/0x678<br /> [ 47.014734] ip_finish_output2+0x598/0x2458<br /> [ 47.018927] __ip_finish_output+0x300/0x730<br /> [ 47.023118] ip_output+0x2e0/0x430<br /> [ 47.026530] ip_local_out+0x90/0x140<br /> [ 47.030117] igmpv3_sendpack+0x14c/0x228<br /> [ 47.034049] igmpv3_send_cr+0x384/0x6b8<br /> [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118<br /> [ 47.042262] call_timer_fn+0x1cc/0xbe8<br /> [ 47.046021] __run_timers+0x4d8/0xb28<br /> [ 47.049693] run_timer_softirq+0x24/0x40<br /> [ 47.053626] __do_softirq+0x2c0/0x117c<br /> [ 47.057387] irq_exit+0x2dc/0x388<br /> [ 47.060715] __handle_domain_irq+0xb4/0x158<br /> [ 47.064908] gic_handle_irq+0x58/0xb0<br /> [ 47.068581] el0_irq_naked+0x50/0x5c<br /> [ 47.072162]<br /> [ 47.073665] Allocated by task 328:<br /> [ 47.077083] save_stack+0x24/0xb0<br /> [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0<br /> [ 47.084776] kasan_slab_alloc+0x14/0x20<br /> [ 47.088622] kmem_cache_alloc+0x15c/0x468<br /> [ 47.092643] __alloc_skb+0xa4/0x498<br /> [ 47.096142] igmpv3_newpack+0x158/0xd78<br /> [ 47.099987] add_grhead+0x210/0x288<br /> [ 47.103485] add_grec+0x6b0/0xb70<br /> [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8<br /> [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118<br /> [ 47.115027] call_timer_fn+0x1cc/0xbe8<br /> [ 47.118785] __run_timers+0x4d8/0xb28<br /> [ 47.122457] run_timer_softirq+0x24/0x40<br /> [ 47.126389] __do_softirq+0x2c0/0x117c<br /> [ 47.130142]<br /> [ 47.131643] Freed by task 180:<br /> [ 47.134712] save_stack+0x24/0xb0<br /> [ 47.138041] __kasan_slab_free+0x108/0x180<br /> [ 47.142146] kasan_slab_free+0x10/0x18<br /> [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0<br /> [ 47.150444] kmem_cache_free+0x8c/0x528<br /> [ 47.154292] kfree_skbmem+0x94/0x108<br /> [ 47.157880] consume_skb+0x10c/0x5a8<br /> [ 47.161466] __dev_kfree_skb_any+0x88/0xa0<br /> [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil]<br /> [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac]<br /> [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac]<br /> [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac]<br /> [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac]<br /> [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac]<br /> [ 47.197859] process_one_work+0x7fc/0x1a80<br /> [ 47.201965] worker_thread+0x31c/0xc40<br /> [ 47.205726] kthread+0x2d8/0x370<br /> [ 47.208967] ret_from_fork+0x10/0x18<br /> [ 47.212546]<br /> [ 47.214051] The buggy address belongs to the object at ffffff803f588280<br /> [ 47.214051] which belongs to the cache skbuff_head_cache of size 208<br /> [ 47.227086] The buggy address is located 104 bytes inside of<br /> [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350)<br /> [ 47.238814] The buggy address belongs to the page:<br /> [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: If sock is dead don&amp;#39;t access sock&amp;#39;s sk_wq in sk_stream_wait_memory<br /> <br /> Fixes the below NULL pointer dereference:<br /> <br /> [...]<br /> [ 14.471200] Call Trace:<br /> [ 14.471562] <br /> [ 14.471882] lock_acquire+0x245/0x2e0<br /> [ 14.472416] ? remove_wait_queue+0x12/0x50<br /> [ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50<br /> [ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50<br /> [ 14.474318] ? remove_wait_queue+0x12/0x50<br /> [ 14.474907] remove_wait_queue+0x12/0x50<br /> [ 14.475480] sk_stream_wait_memory+0x20d/0x340<br /> [ 14.476127] ? do_wait_intr_irq+0x80/0x80<br /> [ 14.476704] do_tcp_sendpages+0x287/0x600<br /> [ 14.477283] tcp_bpf_push+0xab/0x260<br /> [ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500<br /> [ 14.478461] ? __local_bh_enable_ip+0x77/0xe0<br /> [ 14.479096] tcp_bpf_send_verdict+0x105/0x470<br /> [ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0<br /> [ 14.480311] sock_sendmsg+0x2d/0x40<br /> [ 14.480822] ____sys_sendmsg+0x1b4/0x1c0<br /> [ 14.481390] ? copy_msghdr_from_user+0x62/0x80<br /> [ 14.482048] ___sys_sendmsg+0x78/0xb0<br /> [ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150<br /> [ 14.483215] ? __do_fault+0x2a/0x1a0<br /> [ 14.483738] ? do_fault+0x15e/0x5d0<br /> [ 14.484246] ? __handle_mm_fault+0x56b/0x1040<br /> [ 14.484874] ? lock_is_held_type+0xdf/0x130<br /> [ 14.485474] ? find_held_lock+0x2d/0x90<br /> [ 14.486046] ? __sys_sendmsg+0x41/0x70<br /> [ 14.486587] __sys_sendmsg+0x41/0x70<br /> [ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350<br /> [ 14.487822] do_syscall_64+0x34/0x80<br /> [ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> The test scenario has the following flow:<br /> <br /> thread1 thread2<br /> ----------- ---------------<br /> tcp_bpf_sendmsg<br /> tcp_bpf_send_verdict<br /> tcp_bpf_sendmsg_redir sock_close<br /> tcp_bpf_push_locked __sock_release<br /> tcp_bpf_push //inet_release<br /> do_tcp_sendpages sock-&gt;ops-&gt;release<br /> sk_stream_wait_memory // tcp_close<br /> sk_wait_event sk-&gt;sk_prot-&gt;close<br /> release_sock(__sk);<br /> ***<br /> lock_sock(sk);<br /> __tcp_close<br /> sock_orphan(sk)<br /> sk-&gt;sk_wq = NULL<br /> release_sock<br /> ****<br /> lock_sock(__sk);<br /> remove_wait_queue(sk_sleep(sk), &amp;wait);<br /> sk_sleep(sk)<br /> //NULL pointer dereference<br /> &amp;rcu_dereference_raw(sk-&gt;sk_wq)-&gt;wait<br /> <br /> While waiting for memory in thread1, the socket is released with its wait<br /> queue because thread2 has closed it. This caused by tcp_bpf_send_verdict<br /> didn&amp;#39;t increase the f_count of psock-&gt;sk_redir-&gt;sk_socket-&gt;file in thread1.<br /> <br /> We should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory<br /> before accessing the wait queue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Protect against send buffer overflow in NFSv2 READ<br /> <br /> Since before the git era, NFSD has conserved the number of pages<br /> held by each nfsd thread by combining the RPC receive and send<br /> buffers into a single array of pages. This works because there are<br /> no cases where an operation needs a large RPC Call message and a<br /> large RPC Reply at the same time.<br /> <br /> Once an RPC Call has been received, svc_process() updates<br /> svc_rqst::rq_res to describe the part of rq_pages that can be<br /> used for constructing the Reply. This means that the send buffer<br /> (rq_res) shrinks when the received RPC record containing the RPC<br /> Call is large.<br /> <br /> A client can force this shrinkage on TCP by sending a correctly-<br /> formed RPC Call header contained in an RPC record that is<br /> excessively large. The full maximum payload size cannot be<br /> constructed in that case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Fix error code path in acpi_ds_call_control_method()<br /> <br /> A use-after-free in acpi_ps_parse_aml() after a failing invocaion of<br /> acpi_ds_call_control_method() is reported by KASAN [1] and code<br /> inspection reveals that next_walk_state pushed to the thread by<br /> acpi_ds_create_walk_state() is freed on errors, but it is not popped<br /> from the thread beforehand. Thus acpi_ds_get_current_walk_state()<br /> called by acpi_ps_parse_aml() subsequently returns it as the new<br /> walk state which is incorrect.<br /> <br /> To address this, make acpi_ds_call_control_method() call<br /> acpi_ds_pop_walk_state() to pop next_walk_state from the thread before<br /> returning an error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: bridge: adv7511: unregister cec i2c device after cec adapter<br /> <br /> cec_unregister_adapter() assumes that the underlying adapter ops are<br /> callable. For example, if the CEC adapter currently has a valid physical<br /> address, then the unregistration procedure will invalidate the physical<br /> address by setting it to f.f.f.f. Whence the following kernel oops<br /> observed after removing the adv7511 module:<br /> <br /> Unable to handle kernel execution of user memory at virtual address 0000000000000000<br /> Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP<br /> Call trace:<br /> 0x0<br /> adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511]<br /> cec_adap_unconfigure+0x44/0x90 [cec]<br /> __cec_s_phys_addr.part.0+0x68/0x230 [cec]<br /> __cec_s_phys_addr+0x40/0x50 [cec]<br /> cec_unregister_adapter+0xb4/0x118 [cec]<br /> adv7511_remove+0x60/0x90 [adv7511]<br /> i2c_device_remove+0x34/0xe0<br /> device_release_driver_internal+0x114/0x1f0<br /> driver_detach+0x54/0xe0<br /> bus_remove_driver+0x60/0xd8<br /> driver_unregister+0x34/0x60<br /> i2c_del_driver+0x2c/0x68<br /> adv7511_exit+0x1c/0x67c [adv7511]<br /> __arm64_sys_delete_module+0x154/0x288<br /> invoke_syscall+0x48/0x100<br /> el0_svc_common.constprop.0+0x48/0xe8<br /> do_el0_svc+0x28/0x88<br /> el0_svc+0x1c/0x50<br /> el0t_64_sync_handler+0xa8/0xb0<br /> el0t_64_sync+0x15c/0x160<br /> Code: bad PC value<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Protect against this scenario by unregistering i2c_cec after<br /> unregistering the CEC adapter. Duly disable the CEC clock afterwards<br /> too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix use-after-free<br /> <br /> We&amp;#39;ve already freed the assoc_data at this point, so need<br /> to use another copy of the AP (MLD) address instead.