Vulnerabilidades

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

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

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: qcom: fix memory leak in error path<br /> <br /> If for some reason the speedbin length is incorrect, then there is a<br /> memory leak in the error path because we never free the speedbin buffer.<br /> This commit fixes the error path to always free the speedbin buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: geode - Fix PCI device refcount leak<br /> <br /> for_each_pci_dev() is implemented by pci_get_device(). The comment of<br /> pci_get_device() says that it will increase the reference count for the<br /> returned pci_dev and also decrease the reference count for the input<br /> pci_dev @from if it is not NULL.<br /> <br /> If we break for_each_pci_dev() loop with pdev not NULL, we need to call<br /> pci_dev_put() to decrease the reference count. We add a new struct<br /> &amp;#39;amd_geode_priv&amp;#39; to record pointer of the pci_dev and membase, and then<br /> add missing pci_dev_put() for the normal and error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ipw2200: fix memory leak in ipw_wdev_init()<br /> <br /> In the error path of ipw_wdev_init(), exception value is returned, and<br /> the memory applied for in the function is not released. Also the memory<br /> is not released in ipw_pci_probe(). As a result, memory leakage occurs.<br /> So memory release needs to be added to the error path of ipw_wdev_init().