Page 493 of 4351 results (0.016 seconds)

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: 8.1EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: tcp: Fix Use-After-Free in tcp_ao_connect_init Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of tcp_ao_connect_init, 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: tcp: Fix Use-After-Free en tcp_ao_connect_init Dado que call_rcu, que se llama en el recorrido hlist_for_each_entry_rcu de tcp_ao_connect_init, no forma parte de la sección crítica de lectura de RCU, es posible que el El período de gracia de RCU transcurrirá durante el recorrido y la clave quedará gratuita. Para evitar esto, se debe cambiar a hlist_for_each_entry_safe. • https://git.kernel.org/stable/c/7c2ffaf21bd67f73d21560995ce17eaf5fc1d37f https://git.kernel.org/stable/c/ca4fb6c6764b3f75b4f5aa81db1536291897ff7f https://git.kernel.org/stable/c/80e679b352c3ce5158f3f778cfb77eb767e586fb • CWE-416: Use After Free •

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: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921e: fix crash in chip reset fail In case of drv own fail in reset, we may need to run mac_reset several times. The sequence would trigger system crash as the log below. Because we do not re-enable/schedule "tx_napi" before disable it again, the process would keep waiting for state change in napi_diable(). To avoid the problem and keep status synchronize for each run, goto final resource handling if drv own failed. [ 5857.353423] mt7921e 0000:3b:00.0: driver own failed [ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own [ 5859.633430] mt7921e 0000:3b:00.0: driver own failed [ 5859.633444] ------------[ cut here ]------------ [ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d [ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common] [ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150 [ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202 ...... [ 5859.633766] Call Trace: [ 5859.633768] <TASK> [ 5859.633771] mt7921e_mac_reset+0x176/0x6f0 [mt7921e] [ 5859.633778] mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common] [ 5859.633785] ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common] [ 5859.633794] ? __kasan_check_read+0x11/0x20 [ 5859.633802] process_one_work+0x7ee/0x1320 [ 5859.633810] worker_thread+0x53c/0x1240 [ 5859.633818] kthread+0x2b8/0x370 [ 5859.633824] ? • https://git.kernel.org/stable/c/0efaf31dec572d3aac4316c6d952e06d1c33adc4 https://git.kernel.org/stable/c/cdb39e251f864910b2fb6c099b1ef9d12c6e22c7 https://git.kernel.org/stable/c/f7f3001723e337568017e8617974f29bc8b2f595 https://git.kernel.org/stable/c/fa3fbe64037839f448dc569212bafc5a495d8219 •