CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35996 – cpu: Re-enable CPU mitigations by default for !X86 architectures
https://notcve.org/view.php?id=CVE-2024-35996
In the Linux kernel, the following vulnerability has been resolved: cpu: Re-enable CPU mitigations by default for !X86 architectures Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific. Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution. Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time. • https://git.kernel.org/stable/c/70688450dddaf91e12fd4fc625da3297025932c9 https://git.kernel.org/stable/c/9c09773917fbb77dff85b433e1e89123fc5fb530 https://git.kernel.org/stable/c/2978ee7c973ce81b6e51100ba1e5ae001af624b9 https://git.kernel.org/stable/c/c4a9babdd5d5a41a74269a2e1aa1647b1b4c45bb https://git.kernel.org/stable/c/36b32816fbab267611f073223f1b0b816ec5920f https://git.kernel.org/stable/c/38f17d1fbb5bfb56ca1419e2d06376d57a9396f9 https://git.kernel.org/stable/c/8292f4f8dd1b005d0688d726261004f816ef730a https://git.kernel.org/stable/c/fd8547ebc187037cc69441a15c1441aea •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35995 – ACPI: CPPC: Use access_width over bit_width for system memory accesses
https://notcve.org/view.php?id=CVE-2024-35995
In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. [ rjw: Subject and changelog edits, comment adjustments ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: CPPC: use access_width sobre bit_width para accesos a la memoria del sistema. Para alinearse con ACPI 6.3+, dado que bit_width puede ser cualquier valor de 8 bits, no se puede depender de que esté siempre encendido. un límite limpio de 8b. Esto fue descubierto en la plataforma Cobalt 100. • https://git.kernel.org/stable/c/4949affd5288b867cdf115f5b08d6166b2027f87 https://git.kernel.org/stable/c/b54c4632946ae42f2b39ed38abd909bbf78cbcc2 https://git.kernel.org/stable/c/6dfd79ed04c578f1d9a9a41ba5b2015cf9f03fc3 https://git.kernel.org/stable/c/01fc53be672acae37e611c80cc0b4f3939584de3 https://git.kernel.org/stable/c/1b890ae474d19800a6be1696df7fb4d9a41676e4 https://git.kernel.org/stable/c/6cb6b12b78dcd8867a3fdbb1b6d0ed1df2b208d1 https://git.kernel.org/stable/c/2f4a4d63a193be6fd530d180bb13c3592052904c https://access.redhat.com/security/cve/CVE-2024-35995 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35993 – mm: turn folio_test_hugetlb into a PageType
https://notcve.org/view.php?id=CVE-2024-35993
In the Linux kernel, the following vulnerability has been resolved: mm: turn folio_test_hugetlb into a PageType The current folio_test_hugetlb() can be fooled by a concurrent folio split into returning true for a folio which has never belonged to hugetlbfs. This can't happen if the caller holds a refcount on it, but we have a few places (memory-failure, compaction, procfs) which do not and should not take a speculative reference. Since hugetlb pages do not use individual page mapcounts (they are always fully mapped and use the entire_mapcount field to record the number of mappings), the PageType field is available now that page_mapcount() ignores the value in this field. In compaction and with CONFIG_DEBUG_VM enabled, the current implementation can result in an oops, as reported by Luis. This happens since 9c5ccf2db04b ("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks in the PageHuge() testing path. [willy@infradead.org: update vmcoreinfo] Link: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: convierte folio_test_hugetlb en un PageType. El folio_test_hugetlb() actual puede ser engañado por una división de folio concurrente y devuelve verdadero para un folio que nunca ha pertenecido a hugetlbfs. Esto no puede suceder si la persona que llama tiene un recuento sobre él, pero tenemos algunos lugares (fallo de memoria, compactación, procfs) que no toman ni deben tomar una referencia especulativa. Dado que las páginas de Hugetlb no usan recuentos de mapas de páginas individuales (siempre están completamente asignadas y usan el campo Whole_mapcount para registrar el número de asignaciones), el campo PageType está disponible ahora que page_mapcount() ignora el valor en este campo. • https://git.kernel.org/stable/c/9c5ccf2db04b8d7c3df363fdd4856c2b79ab2c6a https://git.kernel.org/stable/c/2431b5f2650dfc47ce782d1ca7b02d6b3916976f https://git.kernel.org/stable/c/9fdcc5b6359dfdaa52a55033bf50e2cedd66eb32 https://git.kernel.org/stable/c/d99e3140a4d33e26066183ff727d8f02f56bec64 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35992 – phy: marvell: a3700-comphy: Fix out of bounds read
https://notcve.org/view.php?id=CVE-2024-35992
In the Linux kernel, the following vulnerability has been resolved: phy: marvell: a3700-comphy: Fix out of bounds read There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr' every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'. Make sure 'gbe_phy_init[addr]' is used when all elements of 'gbe_phy_init_fix' array are handled. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phy: marvell: a3700-comphy: corrección de lectura fuera de los límites. Hay un acceso de lectura fuera de los límites de 'gbe_phy_init_fix[fix_idx].addr' en cada iteración después de que 'fix_idx' alcance ' ARRAY_SIZE(gbe_phy_init_fix)'. Asegúrese de que se utilice 'gbe_phy_init[addr]' cuando se manejen todos los elementos de la matriz 'gbe_phy_init_fix'. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/934337080c6c59b75db76b180b509f218640ad48 https://git.kernel.org/stable/c/976df695f579bbb2914114b4e9974fe4ed1eb813 https://git.kernel.org/stable/c/610f175d2e16fb2436ba7974b990563002c20d07 https://git.kernel.org/stable/c/40406dfbc060503d2e0a9e637e98493c54997b3d https://git.kernel.org/stable/c/e4308bc22b9d46cf33165c9dfaeebcf29cd56f04 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35991 – dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue
https://notcve.org/view.php?id=CVE-2024-35991
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Convert spinlock to mutex to lock evl workqueue drain_workqueue() cannot be called safely in a spinlocked context due to possible task rescheduling. In the multi-task scenario, calling queue_work() while drain_workqueue() will lead to a Call Trace as pushing a work on a draining workqueue is not permitted in spinlocked context. Call Trace: <TASK> ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440 ? report_bug+0x1f8/0x200 ? • https://git.kernel.org/stable/c/c40bd7d9737bdcfb02d42765bc6c59b338151123 https://git.kernel.org/stable/c/758071a35d9f3ffd84ff12169d081412a2f5f098 https://git.kernel.org/stable/c/c9b732a9f73eadc638abdcf0a6d39bc7a0c1af5f https://git.kernel.org/stable/c/d5638de827cff0fce77007e426ec0ffdedf68a44 https://access.redhat.com/security/cve/CVE-2024-35991 https://bugzilla.redhat.com/show_bug.cgi?id=2281843 •