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 ? save_trace+0x59/0x230 ? add_chain_cache+0x109/0x450 validate_chain+0x558/0x800 __lock_acquire+0x4f8/0xb40 ? lockdep_hardirqs_on+0x7d/0x100 lock_acquire+0xd4/0x2d0 ? ice_reset_vf+0x22f/0x4d0 [ice] ? • 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). In this scenario pin was registered twice, so resources are not yet expected to be release until each registered pin/pin pair is unregistered. Currently, the following crash/call trace is produced when ice driver is removed on the system with installed E810T NIC which includes dpll device: WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30 RIP: 0010:dpll_pin_ops+0x20/0x30 Call Trace: ? __warn+0x7f/0x130 ? dpll_pin_ops+0x20/0x30 dpll_msg_add_pin_freq+0x37/0x1d0 dpll_cmd_pin_get_one+0x1c0/0x400 ? __nlmsg_put+0x63/0x80 dpll_pin_event_send+0x93/0x140 dpll_pin_on_pin_unregister+0x3f/0x100 ice_dpll_deinit_pins+0xa1/0x230 [ice] ice_remove+0xf1/0x210 [ice] Fix by adding a parent pointer as a cookie when creating a registration, also when searching for it. • 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. When setting up for write-through, we flush any conflicting writes in the region and wait for the write to complete, failing if there's a write error to return. The issue arises if we're writing at or above the EOF position because we skip the flush and - more importantly - the wait. This becomes a problem if there's a partial folio at the end of the file that is being written out and we want to make a write to it too. Both the already-running write and the write we start both want to clear the writeback mark, but whoever is second causes a warning looking something like: ------------[ cut here ]------------ R=00000012: folio 11 is not under writeback WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105 ... CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ... ... Workqueue: events_unbound netfs_write_collection_worker ... RIP: 0010:netfs_writeback_lookup_folio Fix this by making the flush-and-wait unconditional. It will do nothing if there are no folios in the pagecache and will return quickly if there are no folios in the region specified. Further, move the WBC attachment above the flush call as the flush is going to attach a WBC and detach it again if it is not present - and since we need one anyway we might as well share it. • 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. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: corrige la falta de Hugetlb_lock para descarga de resv. Hay un informe reciente sobre UFFDIO_COPY sobre Hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Debería ser un problema en hugetlb pero se activa en un contexto de error de usuario, donde entra en la ruta poco probable en la que dos subprocesos modifican el mapa resv juntos. Mike tiene una solución en esa ruta para la descarga de resv, pero parece que se pasó por alto el criterio de bloqueo: hugetlb_cgroup_uncharge_folio_rsvd() actualizará el puntero de cgroup, por lo que es necesario llamarlo con el bloqueo retenido. • 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 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35999 – smb3: missing lock when picking channel
https://notcve.org/view.php?id=CVE-2024-35999
In the Linux kernel, the following vulnerability has been resolved: smb3: missing lock when picking channel Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index. Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)") En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb3: falta el bloqueo al seleccionar el canal. Coverity detectó un lugar donde deberíamos haber mantenido el bloqueo del canal al acceder al índice del canal ses. Direcciones-Cobertura: 1582039 ("Condición de ejecución de datos (MISSING_LOCK)") • https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729 https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00 https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887 •