Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: qcom: fix writes in read-only memory region<br /> <br /> This commit fixes a kernel oops because of a write in some read-only memory:<br /> <br /> [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8<br /> ..snip..<br /> [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP<br /> ..snip..<br /> [ 9.269161] Call trace:<br /> [ 9.276271] __memcpy+0x5c/0x230<br /> [ 9.278531] snprintf+0x58/0x80<br /> [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190<br /> [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c<br /> ..snip..<br /> <br /> The following line defines a pointer that point to a char buffer stored<br /> in read-only memory:<br /> <br /> char *pvs_name = "speedXX-pvsXX-vXX";<br /> <br /> This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the<br /> XX values get overridden by the qcom_cpufreq_krait_name_version function. Since<br /> the template is actually stored in read-only memory, when the function<br /> executes the following call we get an oops:<br /> <br /> snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d",<br /> speed, pvs, pvs_ver);<br /> <br /> To fix this issue, we instead store the template name onto the stack by<br /> using the following syntax:<br /> <br /> char pvs_name_buffer[] = "speedXX-pvsXX-vXX";<br /> <br /> Because the `pvs_name` needs to be able to be assigned to NULL, the<br /> template buffer is stored in the pvs_name_buffer and not under the<br /> pvs_name variable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Fix crash on isr after kexec()<br /> <br /> If the system is rebooted via isr(), the IRQ handler might<br /> be triggered before the domain is initialized. Resulting on<br /> an invalid memory access error.<br /> <br /> Fix:<br /> [ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070<br /> [ 0.501166] Call trace:<br /> [ 0.501174] report_iommu_fault+0x28/0xfc<br /> [ 0.501180] mtk_iommu_isr+0x10c/0x1c0<br /> <br /> [ joro: Fixed spelling in commit message ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: fix possible UAF when kfifo_alloc() fails<br /> <br /> If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free<br /> priv. But priv is still in the chdev-&gt;file_list, then list traversal<br /> may cause UAF. This fixes the following smatch warning:<br /> <br /> drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: &amp;#39;&amp;priv-&gt;list&amp;#39; not removed from list

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()<br /> <br /> If device_register() fails in cxl_pci_afu|adapter(), the device<br /> is not added, device_unregister() can not be called in the error<br /> path, otherwise it will cause a null-ptr-deref because of removing<br /> not added device.<br /> <br /> As comment of device_register() says, it should use put_device() to give<br /> up the reference in the error path. So split device_unregister() into<br /> device_del() and put_device(), then goes to put dev when register fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: handle the error returned from sctp_auth_asoc_init_active_key<br /> <br /> When it returns an error from sctp_auth_asoc_init_active_key(), the<br /> active_key is actually not updated. The old sh_key will be freeed<br /> while it&amp;#39;s still used as active key in asoc. Then an use-after-free<br /> will be triggered when sending patckets, as found by syzbot:<br /> <br /> sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112<br /> sctp_set_owner_w net/sctp/socket.c:132 [inline]<br /> sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863<br /> sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025<br /> inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> <br /> This patch is to fix it by not replacing the sh_key when it returns<br /> errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().<br /> For sctp_auth_set_active_key(), old active_key_id will be set back<br /> to asoc-&gt;active_key_id when the same thing happens.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()<br /> <br /> If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp<br /> needs to be freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix use-after-free on source server when doing inter-server copy<br /> <br /> Use-after-free occurred when the laundromat tried to free expired<br /> cpntf_state entry on the s2s_cp_stateids list after inter-server<br /> copy completed. The sc_cp_list that the expired copy state was<br /> inserted on was already freed.<br /> <br /> When COPY completes, the Linux client normally sends LOCKU(lock_state x),<br /> FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server.<br /> The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state<br /> from the s2s_cp_stateids list before freeing the lock state&amp;#39;s stid.<br /> <br /> However, sometimes the CLOSE was sent before the FREE_STATEID request.<br /> When this happens, the nfsd4_close_open_stateid call from nfsd4_close<br /> frees all lock states on its st_locks list without cleaning up the copy<br /> state on the sc_cp_list list. When the time the FREE_STATEID arrives the<br /> server returns BAD_STATEID since the lock state was freed. This causes<br /> the use-after-free error to occur when the laundromat tries to free<br /> the expired cpntf_state.<br /> <br /> This patch adds a call to nfs4_free_cpntf_statelist in<br /> nfsd4_close_open_stateid to clean up the copy state before calling<br /> free_ol_stateid_reaplist to free the lock state&amp;#39;s stid on the reaplist.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Protect against send buffer overflow in NFSv2 READDIR<br /> <br /> Restore the previous limit on the @count argument to prevent a<br /> buffer overflow attack.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/af_unix: defer registered files gc to io_uring release<br /> <br /> Instead of putting io_uring&amp;#39;s registered files in unix_gc() we want it<br /> to be done by io_uring itself. The trick here is to consider io_uring<br /> registered files for cycle detection but not actually putting them down.<br /> Because io_uring can&amp;#39;t register other ring instances, this will remove<br /> all refs to the ring file triggering the -&gt;release path and clean up<br /> with io_ring_ctx_free().<br /> <br /> [axboe: add kerneldoc comment to skb, fold in skb leak fix]

*** Pendiente de traducción *** Elevation of Privileges in the cleaning feature of Gen Digital CCleaner version 6.33.11465 on Windows allows a local user to gain SYSTEM privileges via exploiting insecure file delete operations. Reported in CCleaner v. 6.33.11465. This issue affects CCleaner: before

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()<br /> <br /> If we find an unexpected generation for the extent buffer we are cloning<br /> at btrfs_copy_root(), we just WARN_ON() and don&amp;#39;t error out and abort the<br /> transaction, meaning we allow to persist metadata with an unexpected<br /> generation. Instead of warning only, abort the transaction and return<br /> -EUCLEAN.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: Remove WARN_ON for device endpoint command timeouts<br /> <br /> This commit addresses a rarely observed endpoint command timeout<br /> which causes kernel panic due to warn when &amp;#39;panic_on_warn&amp;#39; is enabled<br /> and unnecessary call trace prints when &amp;#39;panic_on_warn&amp;#39; is disabled.<br /> It is seen during fast software-controlled connect/disconnect testcases.<br /> The following is one such endpoint command timeout that we observed:<br /> <br /> 1. Connect<br /> =======<br /> -&gt;dwc3_thread_interrupt<br /> -&gt;dwc3_ep0_interrupt<br /> -&gt;configfs_composite_setup<br /> -&gt;composite_setup<br /> -&gt;usb_ep_queue<br /> -&gt;dwc3_gadget_ep0_queue<br /> -&gt;__dwc3_gadget_ep0_queue<br /> -&gt;__dwc3_ep0_do_control_data<br /> -&gt;dwc3_send_gadget_ep_cmd<br /> <br /> 2. Disconnect<br /> ==========<br /> -&gt;dwc3_thread_interrupt<br /> -&gt;dwc3_gadget_disconnect_interrupt<br /> -&gt;dwc3_ep0_reset_state<br /> -&gt;dwc3_ep0_end_control_data<br /> -&gt;dwc3_send_gadget_ep_cmd<br /> <br /> In the issue scenario, in Exynos platforms, we observed that control<br /> transfers for the previous connect have not yet been completed and end<br /> transfer command sent as a part of the disconnect sequence and<br /> processing of USB_ENDPOINT_HALT feature request from the host timeout.<br /> This maybe an expected scenario since the controller is processing EP<br /> commands sent as a part of the previous connect. It maybe better to<br /> remove WARN_ON in all places where device endpoint commands are sent to<br /> avoid unnecessary kernel panic due to warn.