CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36006 – mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
https://notcve.org/view.php?id=CVE-2024-36006
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix incorrect list API usage Both the function that migrates all the chunks within a region and the function that migrates all the entries within a chunk call list_first_entry() on the respective lists without checking that the lists are not empty. This is incorrect usage of the API, which leads to the following warning [1]. Fix by returning if the lists are empty as there is nothing to migrate in this case. [1] WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Modules linked in: CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [...] Call Trace: <TASK> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige el uso incorrecto de la API de lista. Tanto la función que migra todos los fragmentos dentro de una región como la función que migra todas las entradas dentro de un fragmento llaman a list_first_entry() en el respectivo listas sin verificar que las listas no estén vacías. Este es un uso incorrecto de la API, lo que genera la siguiente advertencia [1]. • https://git.kernel.org/stable/c/6f9579d4e3021b17b0a4cde6b04a6c94c9575cdf https://git.kernel.org/stable/c/0b2c13b670b168e324e1cf109e67056a20fd610a https://git.kernel.org/stable/c/09846c2309b150b8ce4e0ce96f058197598fc530 https://git.kernel.org/stable/c/64435b64e43d8ee60faa46c0cd04e323e8b2a7b0 https://git.kernel.org/stable/c/4526a56e02da3725db979358964df9cd9c567154 https://git.kernel.org/stable/c/ab4ecfb627338e440ae11def004c524a00d93e40 https://git.kernel.org/stable/c/af8b593c3dd9df82cb199be65863af004b09fd97 https://git.kernel.org/stable/c/b377add0f0117409c418ddd6504bd682e •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36005 – netfilter: nf_tables: honor table dormant flag from netdev release event path
https://notcve.org/view.php?id=CVE-2024-36005
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: honor table dormant flag from netdev release event path Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook. [524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanup_net [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? • https://git.kernel.org/stable/c/d54725cd11a57c30f650260cfb0a92c268bdc3e0 https://git.kernel.org/stable/c/e4bb6da24de336a7899033a65490ed2d892efa5b https://git.kernel.org/stable/c/5c45feb3c288cf44a529e2657b36c259d86497d2 https://git.kernel.org/stable/c/13ba94f6cc820fdea15efeaa17d4c722874eebf9 https://git.kernel.org/stable/c/8260c980aee7d8d8a3db39faf19c391d2f898816 https://git.kernel.org/stable/c/ca34c40d1c22c555fa7f4a21a1c807fea7290a0a https://git.kernel.org/stable/c/8e30abc9ace4f0add4cd761dfdbfaebae5632dd2 https://lists.debian.org/debian-lts-announce/2024/06/ •
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. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not. Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too. [Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40e_service_task [i40e] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? __warn+0x80/0x130 [ +0.000003] ? • 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: 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 •