Page 308 of 2059 results (0.005 seconds)

CVSS: 5.3EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: qibfs: fix dentry leak simple_recursive_removal() drops the pinning references to all positives in subtree. For the cases when its argument has been kept alive by the pinning alone that's exactly the right thing to do, but here the argument comes from dcache lookup, that needs to be balanced by explicit dput(). Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: qibfs: arreglar la fuga de dentry simple_recursive_removal() elimina las referencias de fijación a todos los positivos en el subárbol. Para los casos en los que su argumento se ha mantenido vivo solo mediante la fijación, eso es exactamente lo correcto, pero aquí el argumento proviene de la búsqueda de dcache, que debe equilibrarse con dput() explícito. Jodido por: Al Viro • https://git.kernel.org/stable/c/e41d237818598c0b17458b4d0416b091a7959e55 https://git.kernel.org/stable/c/24dd9b08df718f20ccf2dd1519909fefd8c233ee https://git.kernel.org/stable/c/bd8f78c71defbcb7a9ed331e7f287507df972b00 https://git.kernel.org/stable/c/db71ca93259dd1078bcfea3afafde2143cfc2da7 https://git.kernel.org/stable/c/02ee394a5d899d9bd2f0759382e9481cab6166f8 https://git.kernel.org/stable/c/aa23317d0268b309bb3f0801ddd0d61813ff5afb •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: phonet: fix rtm_phonet_notify() skb allocation fill_route() stores three components in the skb: - struct rtmsg - RTA_DST (u8) - RTA_OIF (u32) Therefore, rtm_phonet_notify() should use NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phonet: corrige la asignación de skb de rtm_phonet_notify() fill_route() almacena tres componentes en el skb: - struct rtmsg - RTA_DST (u8) - RTA_OIF (u32) Por lo tanto, rtm_phonet_notify() debería usar NLMSG_ALIGN(tamañode(struct rtmsg)) + nla_total_size(1) + nla_total_size(4) • https://git.kernel.org/stable/c/f062f41d06575744b9eaf725eef8a5d3b5f5b7ca https://git.kernel.org/stable/c/ec1f71c05caeba0f814df77e0f511d8b4618623a https://git.kernel.org/stable/c/dc6beac059f0331de97155a89d84058d4a9e49c7 https://git.kernel.org/stable/c/f085e02f0a32f6dfcfabc6535c9c4a1707cef86b https://git.kernel.org/stable/c/4ff334cade9dae50e4be387f71e94fae634aa9b4 https://git.kernel.org/stable/c/728a83160f98ee6b60df0d890141b9b7240182fe https://git.kernel.org/stable/c/ee9e39a6cb3ca2a3d35b4ae25547ee3526a44d00 https://git.kernel.org/stable/c/9a77226440008cf04ba68faf641a2d50f •

CVSS: 3.3EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/smc: fix neighbour and rtable leak in smc_ib_find_route() In smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable resolved by ip_route_output_flow() are not released or put before return. It may cause the refcount leak, so fix it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige la fuga de vecino y rtable en smc_ib_find_route() En smc_ib_find_route(), el vecino encontrado por neigh_lookup() y rtable resuelto por ip_route_output_flow() no se liberan ni se colocan antes devolver. Puede causar la fuga de recuento, así que corríjalo. • https://git.kernel.org/stable/c/e5c4744cfb598f98672f8d21d59ef2c1fa9c9b5f https://git.kernel.org/stable/c/d5a466ab6e78d6f2e0f64435f1e17246c8e941ff https://git.kernel.org/stable/c/5df93c029a907b0ff5a4eeadd77ba06ff0a277d2 https://git.kernel.org/stable/c/da91e447d06dc649fcf46e59122e7bf8f0b2e0db https://git.kernel.org/stable/c/2ddc0dd7fec86ee53b8928a5cca5fbddd4fc7c06 https://access.redhat.com/security/cve/CVE-2024-36945 https://bugzilla.redhat.com/show_bug.cgi?id=2284465 • CWE-401: Missing Release of Memory after Effective Lifetime •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: Reapply "drm/qxl: simplify qxl_fence_wait" This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea. Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds" and further debugging points to a possible circular locking dependency between the console_owner locking and the worker pool locking. Reverting the commit allows Steve's VM to boot to completion again. [ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Vuelva a aplicar "drm/qxl: simplificar qxl_fence_wait" Esto revierte el commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea. Stephen Rostedt informa: "Fui a ejecutar mis pruebas en mis máquinas virtuales y las pruebas se colgaron al arrancar. Desafortunadamente, lo máximo que obtuve fue: [ 93.607888] Probando evento de initcall del sistema: OK [ 93.667730] Ejecutando pruebas en todos los eventos de seguimiento : [93.669757] Probando todos los eventos: OK [95.631064] ------------[ cortar aquí ]------------ Se agotó el tiempo de espera después de 60 segundos" y más puntos de depuración a una posible dependencia de bloqueo circular entre el bloqueo del propietario de la consola y el bloqueo del grupo de trabajadores. Revertir el commit permite que la máquina virtual de Steve se inicie nuevamente. • https://git.kernel.org/stable/c/4a89ac4b0921c4ea21eb1b4cf3a469a91bacfcea https://git.kernel.org/stable/c/b548c53bc3ab83dc6fc86c8e840f013b2032267a https://git.kernel.org/stable/c/148ed8b4d64f94ab079c8f0d88c3f444db97ba97 https://git.kernel.org/stable/c/3dfe35d8683daf9ba69278643efbabe40000bbf6 https://git.kernel.org/stable/c/3628e0383dd349f02f882e612ab6184e4bb3dc10 https://access.redhat.com/security/cve/CVE-2024-36944 https://bugzilla.redhat.com/show_bug.cgi?id=2284468 • CWE-833: Deadlock •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan make_uffd_wp_pte() was previously doing: pte = ptep_get(ptep); ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); But if another thread accessed or dirtied the pte between the first 2 calls, this could lead to loss of that information. Since ptep_modify_prot_start() gets and clears atomically, the following is the correct pattern and prevents any possible race. Any access after the first call would see an invalid pte and cause a fault: pte = ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep, pte); En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/proc/task_mmu: corrige la pérdida de bits jóvenes/sucios durante el escaneo del mapa de páginas que make_uffd_wp_pte() estaba haciendo anteriormente: pte = ptep_get(ptep); ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep,pte); Pero si otro hilo accedió o ensució el pte entre las 2 primeras llamadas, esto podría provocar la pérdida de esa información. Dado que ptep_modify_prot_start() obtiene y borra atómicamente, el siguiente es el patrón correcto y evita cualquier posible ejecución. Cualquier acceso después de la primera llamada vería un pte no válido y provocaría una falla: pte = ptep_modify_prot_start(ptep); pte = pte_mkuffd_wp(pte); ptep_modify_prot_commit(ptep,pte); • https://git.kernel.org/stable/c/52526ca7fdb905a768a93f8faa418e9b988fc34b https://git.kernel.org/stable/c/74b3d66f91d9f539f99faad74d796fa9a389a015 https://git.kernel.org/stable/c/c70dce4982ce1718bf978a35f8e26160b82081f4 •