Page 355 of 3407 results (0.058 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gtp: corrige Use-After-Free en gtp_dellink Dado que call_rcu, que se llama en el recorrido hlist_for_each_entry_rcu de gtp_dellink, no forma parte de la sección crítica de lectura de RCU, es posible que el período de gracia de RCU pasará durante el recorrido y la clave quedará libre. Para evitar esto, se debe cambiar a hlist_for_each_entry_safe. • https://git.kernel.org/stable/c/043a283d24f40fea4c8a8d06b0e2694c8e372200 https://git.kernel.org/stable/c/c185e1d6e2752a4b656c3ca878c525fa11f55757 https://git.kernel.org/stable/c/94dc550a5062030569d4aa76e10e50c8fc001930 https://git.kernel.org/stable/c/a29c4303930bc0c25ae6a4f365dcdef71447b4ea https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58 https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7 https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff366 •

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

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: Fix Use-After-Free en ovs_ct_exit Dado que kfree_rcu, que se llama en el recorrido hlist_for_each_entry_rcu de ovs_ct_limit_exit, no forma parte de la sección crítica de lectura de RCU, es posible que el período de gracia de RCU pasará durante el recorrido y la clave quedará libre. Para evitar esto, se debe cambiar a hlist_for_each_entry_safe. • https://git.kernel.org/stable/c/11efd5cb04a184eea4f57b68ea63dddd463158d1 https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994 https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424 https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3 https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4 https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1 https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137 https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e •

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

In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks"). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: xen-netfront: agrega skb_mark_for_recycle faltante. Tenga en cuenta que skb_mark_for_recycle() se introduce más tarde que la etiqueta de corrección en el commit 6a5bcd84e886 ("page_pool: permitir que los controladores indiquen el reciclaje de SKB"). Se cree que a la etiqueta de correcciones le faltaba una llamada a page_pool_release_page() entre v5.9 y v5.14, después de lo cual debería haber usado skb_mark_for_recycle(). Desde v6.6, la llamada page_pool_release_page() se eliminó (en el commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") y las personas que llaman restantes se convirtieron (en el commit 6bfef2ec0172 ("Merge Branch 'net-page_pool-remove-page_pool_release_page'") ). • https://git.kernel.org/stable/c/6c5aa6fc4defc2a0977a2c59e4710d50fa1e834c https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1 https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6 https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629 https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4 https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f http://www.openwall.com/lists/oss-security/2024/05/08/4 http://xenbits.xen.org/xsa/advisory-457.html https:& •

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

In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: disable sending io_uring over sockets File reference cycles have caused lots of problems for io_uring in the past, and it still doesn't work exactly right and races with unix_stream_read_generic(). The safest fix would be to completely disallow sending io_uring files via sockets via SCM_RIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: io_uring/af_unix: deshabilita el envío de io_uring a través de sockets Los ciclos de referencia de archivos han causado muchos problemas para io_uring en el pasado, y todavía no funciona exactamente correctamente y corre con unix_stream_read_generic(). La solución más segura sería no permitir por completo el envío de archivos io_uring a través de sockets a través de SCM_RIGHT, de modo que no haya ciclos posibles que involucren archivos registrados y, por lo tanto, hagan innecesaria la contabilidad SCM en el lado io_uring. • https://github.com/FoxyProxys/CVE-2023-52654 https://git.kernel.org/stable/c/04df9719df1865f6770af9bc7880874af0e594b2 https://git.kernel.org/stable/c/c378c479c5175833bb22ff71974cda47d7b05401 https://git.kernel.org/stable/c/813d8fe5d30388f73a21d3a2bf46b0a1fd72498c https://git.kernel.org/stable/c/0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 https://git.kernel.org/stable/c/b4293c01ee0d0ecdd3cb5801e13f62271144667a https://git.kernel.org/stable/c/75e94c7e8859e58aadc15a98cc9704edff47d4f2 https://git.kernel.org/stable/c/18824f592aad4124d79751bbc1500ea86ac3ff29 https:/& •

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

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: add a force flush to delay work when radeon Although radeon card fence and wait for gpu to finish processing current batch rings, there is still a corner case that radeon lockup work queue may not be fully flushed, and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to put device in D3hot state. Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State. > Configuration and Message requests are the only TLPs accepted by a Function in > the D3hot state. All other received Requests must be handled as Unsupported Requests, > and all received Completions may optionally be handled as Unexpected Completions. This issue will happen in following logs: Unable to handle kernel paging request at virtual address 00008800e0008010 CPU 0 kworker/0:3(131): Oops 0 pc = [<ffffffff811bea5c>] ra = [<ffffffff81240844>] ps = 0000 Tainted: G W pc is at si_gpu_check_soft_reset+0x3c/0x240 ra is at si_dma_is_lockup+0x34/0xd0 v0 = 0000000000000000 t0 = fff08800e0008010 t1 = 0000000000010000 t2 = 0000000000008010 t3 = fff00007e3c00000 t4 = fff00007e3c00258 t5 = 000000000000ffff t6 = 0000000000000001 t7 = fff00007ef078000 s0 = fff00007e3c016e8 s1 = fff00007e3c00000 s2 = fff00007e3c00018 s3 = fff00007e3c00000 s4 = fff00007fff59d80 s5 = 0000000000000000 s6 = fff00007ef07bd98 a0 = fff00007e3c00000 a1 = fff00007e3c016e8 a2 = 0000000000000008 a3 = 0000000000000001 a4 = 8f5c28f5c28f5c29 a5 = ffffffff810f4338 t8 = 0000000000000275 t9 = ffffffff809b66f8 t10 = ff6769c5d964b800 t11= 000000000000b886 pv = ffffffff811bea20 at = 0000000000000000 gp = ffffffff81d89690 sp = 00000000aa814126 Disabling lock debugging due to kernel taint Trace: [<ffffffff81240844>] si_dma_is_lockup+0x34/0xd0 [<ffffffff81119610>] radeon_fence_check_lockup+0xd0/0x290 [<ffffffff80977010>] process_one_work+0x280/0x550 [<ffffffff80977350>] worker_thread+0x70/0x7c0 [<ffffffff80977410>] worker_thread+0x130/0x7c0 [<ffffffff80982040>] kthread+0x200/0x210 [<ffffffff809772e0>] worker_thread+0x0/0x7c0 [<ffffffff80981f8c>] kthread+0x14c/0x210 [<ffffffff80911658>] ret_from_kernel_thread+0x18/0x20 [<ffffffff80981e40>] kthread+0x0/0x210 Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101 <88210000> 4821ed21 So force lockup work queue flush to fix this problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: agregue un vaciado forzado para retrasar el trabajo cuando radeon. Aunque la tarjeta radeon protege y espera a que la gpu termine de procesar los anillos de lotes actuales, todavía existe un caso de esquina en el que el bloqueo de radeon funciona. Es posible que la cola no se haya vaciado por completo y, mientras tanto, la función radeon_suspend_kms() ha llamado a pci_set_power_state() para poner el dispositivo en estado D3hot. • https://git.kernel.org/stable/c/b878da58df2c40b08914d3960e2224040fd1fbfe https://git.kernel.org/stable/c/4e25e8f27fdbdc6fd55cc572a9939bf24500b9e8 https://git.kernel.org/stable/c/c0a45f41fde4a0f2c900f719817493ee5c4a5aa3 https://git.kernel.org/stable/c/c72d97146fc5a4dff381b1737f6167e89860430d https://git.kernel.org/stable/c/826b46fd5974113515abe9e4fc8178009a8ce18c https://git.kernel.org/stable/c/5a7a5b2edac4b05abd744eeaebda46d9dacd952d https://git.kernel.org/stable/c/16cb367daa446923d82e332537f446a4cc784b40 https://git.kernel.org/stable/c/f461950fdc374a3ada5a63c669d997de4 •