CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36004 – i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
https://notcve.org/view.php?id=CVE-2024-36004
In the Linux kernel, the following vulnerability has been resolved: i40e: Do not use WQ_MEM_RECLAIM flag for workqueue Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. ... check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000024] process_one_work+0x174/0x340 [ +0.000003] worker_th ---truncated--- En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: no utilice el indicador WQ_MEM_RECLAIM para la cola de trabajo Problema informado por el cliente durante las pruebas SRIOV, seguimiento de llamadas: cuando se cargan tanto el i40e como el controlador i40iw, se activa una advertencia en check_flush_dependency. • https://git.kernel.org/stable/c/4d5957cbdecdbb77d24c1465caadd801c07afa4a https://git.kernel.org/stable/c/09b54d29f05129b092f7c793a70b689ffb3c7b2c https://git.kernel.org/stable/c/546d0fe9d76e8229a67369f9cb61e961d99038bd https://git.kernel.org/stable/c/fbbb2404340dd6178e281bd427c271f7d5ec1d22 https://git.kernel.org/stable/c/ff7431f898dd00892a545b7d0ce7adf5b926944f https://git.kernel.org/stable/c/152ed360cf2d273f88fc99a518b7eb868aae2939 https://git.kernel.org/stable/c/8d6105f637883c8c09825e962308c06e977de4f0 https://git.kernel.org/stable/c/1594dac8b1ed78f9e75c263327e198a2e •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36003 – ice: fix LAG and VF lock dependency in ice_reset_vf()
https://notcve.org/view.php?id=CVE-2024-36003
In the Linux kernel, the following vulnerability has been resolved: ice: fix LAG and VF lock dependency in ice_reset_vf() 9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf(). The commit placed this lock acquisition just prior to the acquisition of the VF configuration lock. If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK flag, this could deadlock with ice_vc_cfg_qs_msg() because it always acquires the locks in the order of the VF configuration lock and then the LAG mutex. Lockdep reports this violation almost immediately on creating and then removing 2 VF: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-rc6 #54 Tainted: G W O ------------------------------------------------------ kworker/60:3/6771 is trying to acquire lock: ff40d43e099380a0 (&vf->cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice] but task is already holding lock: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&pf->lag_mutex){+.+.}-{3:3}: __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_vc_cfg_qs_msg+0x45/0x690 [ice] ice_vc_process_vf_msg+0x4f5/0x870 [ice] __ice_clean_ctrlq+0x2b5/0x600 [ice] ice_service_task+0x2c9/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30 -> #0 (&vf->cfg_lock){+.+.}-{3:3}: check_prev_add+0xe2/0xc50 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 lock_acquire+0xd4/0x2d0 __mutex_lock+0x9b/0xbf0 ice_reset_vf+0x22f/0x4d0 [ice] ice_process_vflr_event+0x98/0xd0 [ice] ice_service_task+0x1cc/0x480 [ice] process_one_work+0x1e9/0x4d0 worker_thread+0x1e1/0x3d0 kthread+0x104/0x140 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1b/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pf->lag_mutex); lock(&vf->cfg_lock); lock(&pf->lag_mutex); lock(&vf->cfg_lock); *** DEADLOCK *** 4 locks held by kworker/60:3/6771: #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #1: ff50d06e05197e58 ((work_completion)(&pf->serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0 #2: ff40d43ea1960e50 (&pf->vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice] #3: ff40d43ea1961210 (&pf->lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice] stack backtrace: CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54 Hardware name: Workqueue: ice ice_service_task [ice] Call Trace: <TASK> dump_stack_lvl+0x4a/0x80 check_noncircular+0x12d/0x150 check_prev_add+0xe2/0xc50 ? ... __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> To avoid deadlock, we must acquire the LAG ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la dependencia de bloqueo de LAG y VF en ice_reset_vf() 9f74a3dfcf83 ("ice: corrige las rutas de restablecimiento de VF cuando la interfaz está en un agregado de conmutación por error"), el controlador ice ha adquirido el LAG mutex en ice_reset_vf(). • https://git.kernel.org/stable/c/fd7f7a8ad3363fd94fc3868616cc70a1d8dfc01b https://git.kernel.org/stable/c/9f74a3dfcf83e11aedcb98250b8040dbc6d9659a https://git.kernel.org/stable/c/740717774dc37338404d10726967d582414f638c https://git.kernel.org/stable/c/de8631d8c9df08440268630200e64b623a5f69e6 https://git.kernel.org/stable/c/96fdd1f6b4ed72a741fb0eb705c0e13049b8721f https://access.redhat.com/security/cve/CVE-2024-36003 https://bugzilla.redhat.com/show_bug.cgi?id=2281958 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36002 – dpll: fix dpll_pin_on_pin_register() for multiple parent pins
https://notcve.org/view.php?id=CVE-2024-36002
In the Linux kernel, the following vulnerability has been resolved: dpll: fix dpll_pin_on_pin_register() for multiple parent pins In scenario where pin is registered with multiple parent pins via dpll_pin_on_pin_register(..), all belonging to the same dpll device. A second call to dpll_pin_on_pin_unregister(..) would cause a call trace, as it tries to use already released registration resources (due to fix introduced in b446631f355e). ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dpll: corrige dpll_pin_on_pin_register() para múltiples pines principales En un escenario donde el pin se registra con múltiples pines principales a través de dpll_pin_on_pin_register(..), todos pertenecientes al mismo dispositivo dpll. • https://git.kernel.org/stable/c/b27e32e9367dac024cd6f61f22655714f483fd67 https://git.kernel.org/stable/c/769324eb35143462542cdb15483cdaf4877bf661 https://git.kernel.org/stable/c/f3e1cf62d18220a3aa97e084e7a3552debece9fc https://git.kernel.org/stable/c/38d7b94e81d068b8d8c8392f421cfd2c3bbfd1a6 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36001 – netfs: Fix the pre-flush when appending to a file in writethrough mode
https://notcve.org/view.php?id=CVE-2024-36001
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix the pre-flush when appending to a file in writethrough mode In netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH or O_*SYNC or RWF_*SYNC was specified, write-through caching is performed on a buffered file. ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: soluciona el lavado previo al agregar un archivo en modo de escritura directa. • https://git.kernel.org/stable/c/41d8e7673a7726cba57cb8112d81c89cfb6c3e35 https://git.kernel.org/stable/c/5eaf23b2e81349f6614f88396dc468fda89fc0b9 https://git.kernel.org/stable/c/c97f59e276d4e93480f29a70accbd0d7273cf3f5 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36000 – mm/hugetlb: fix missing hugetlb_lock for resv uncharge
https://notcve.org/view.php?id=CVE-2024-36000
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix missing hugetlb_lock for resv uncharge There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. ... En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrige la falta de Hugetlb_lock para descarga de resv. ... The following vulnerability has been resolved in the Linux kernel: mm/hugetlb: fix missing hugetlb_lock for resv uncharge. • https://git.kernel.org/stable/c/79aa925bf239c234be8586780e482872dc4690dd https://git.kernel.org/stable/c/f87004c0b2bdf0f1066b88795d8e6c1dfad6cea0 https://git.kernel.org/stable/c/4c806333efea1000a2a9620926f560ad2e1ca7cc https://git.kernel.org/stable/c/f6c5d21db16a0910152ec8aa9d5a7aed72694505 https://git.kernel.org/stable/c/538faabf31e9c53d8c870d114846fda958a0de10 https://git.kernel.org/stable/c/b76b46902c2d0395488c8412e1116c2486cdfcb2 https://access.redhat.com/security/cve/CVE-2024-36000 https://bugzilla.redhat.com/show_bug.cgi?id=2281968 •