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 /> android: binder: stop saving a pointer to the VMA<br /> <br /> Do not record a pointer to a VMA outside of the mmap_lock for later use. <br /> This is unsafe and there are a number of failure paths *after* the<br /> recorded VMA pointer may be freed during setup. There is no callback to<br /> the driver to clear the saved pointer from generic mm code. Furthermore,<br /> the VMA pointer may become stale if any number of VMA operations end up<br /> freeing the VMA so saving it was fragile to being with.<br /> <br /> Instead, change the binder_alloc struct to record the start address of the<br /> VMA and use vma_lookup() to get the vma when needed. Add lockdep<br /> mmap_lock checks on updates to the vma pointer to ensure the lock is held<br /> and depend on that lock for synchronization of readers and writers - which<br /> was already the case anyways, so the smp_wmb()/smp_rmb() was not<br /> necessary.<br /> <br /> [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]

*** 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 /> 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 /> 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 /> 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 /> 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 /> 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 *** 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 *** 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 /> lib/crypto: arm/poly1305: Fix register corruption in no-SIMD contexts<br /> <br /> Restore the SIMD usability check that was removed by commit 773426f4771b<br /> ("crypto: arm/poly1305 - Add block-only interface").<br /> <br /> This safety check is cheap and is well worth eliminating a footgun.<br /> While the Poly1305 functions should not be called when SIMD registers<br /> are unusable, if they are anyway, they should just do the right thing<br /> instead of corrupting random tasks&amp;#39; registers and/or computing incorrect<br /> MACs. Fixing this is also needed for poly1305_kunit to pass.<br /> <br /> Just use may_use_simd() instead of the original crypto_simd_usable(),<br /> since poly1305_kunit won&amp;#39;t rely on crypto_simd_disabled_for_test.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Remove WARN_ON_ONCE() call from ufshcd_uic_cmd_compl()<br /> <br /> The UIC completion interrupt may be disabled while an UIC command is<br /> being processed. When the UIC completion interrupt is reenabled, an UIC<br /> interrupt is triggered and the WARN_ON_ONCE(!cmd) statement is hit.<br /> Hence this patch that removes this kernel warning.