CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27434 – wifi: iwlwifi: mvm: don't set the MFP flag for the GTK
https://notcve.org/view.php?id=CVE-2024-27434
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't set the MFP flag for the GTK The firmware doesn't need the MFP flag for the GTK, it can even make the firmware crash. in case the AP is configured with: group cipher TKIP and MFPC. We would send the GTK with cipher = TKIP and MFP which is of course not possible. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no configure el indicador MFP para GTK El firmware no necesita el indicador MFP para GTK, incluso puede provocar que el firmware falle. en caso de que el AP esté configurado con: cifrado de grupo TKIP y MFPC. Enviaríamos el GTK con cifrado = TKIP y MFP, lo cual, por supuesto, no es posible. • https://git.kernel.org/stable/c/5c75a208c2449c6ea24f07610cc052f6a352246c https://git.kernel.org/stable/c/b4f1b0b3b91762edd19bf9d3b2e4c3a0740501f8 https://git.kernel.org/stable/c/40405cbb20eb6541c603e7b3d54ade0a7be9d715 https://git.kernel.org/stable/c/60f6d5fc84a9fd26528a24d8a267fc6a6698b628 https://git.kernel.org/stable/c/e35f316bce9e5733c9826120c1838f4c447b2c4c https://access.redhat.com/security/cve/CVE-2024-27434 https://bugzilla.redhat.com/show_bug.cgi?id=2281133 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-27433 – clk: mediatek: mt7622-apmixedsys: Fix an error handling path in clk_mt8135_apmixed_probe()
https://notcve.org/view.php?id=CVE-2024-27433
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: mt7622-apmixedsys: Fix an error handling path in clk_mt8135_apmixed_probe() 'clk_data' is allocated with mtk_devm_alloc_clk_data(). So calling mtk_free_clk_data() explicitly in the remove function would lead to a double-free. Remove the redundant call. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: clk: mediatek: mt7622-apmixedsys: se corrigió una ruta de manejo de errores en clk_mt8135_apmixed_probe() 'clk_data' se asigna con mtk_devm_alloc_clk_data(). Entonces, llamar explícitamente a mtk_free_clk_data() en la función de eliminación conduciría a un double free. Eliminar la llamada redundante. • https://git.kernel.org/stable/c/c50e2ea6507bcf5a4475f821fc03dd1fdcb894a7 https://git.kernel.org/stable/c/de3340533bd68a7b3d6be1841b8eb3fa6c762fe6 https://git.kernel.org/stable/c/f3633fed984f1db106ff737a0bb52fadb2d89ac7 https://git.kernel.org/stable/c/fa761ce7a1d15cca1a306b3635f81a22b15fee5b https://git.kernel.org/stable/c/a32e88f2b20259f5fe4f8eed598bbc85dc4879ed •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-27432 – net: ethernet: mtk_eth_soc: fix PPE hanging issue
https://notcve.org/view.php?id=CVE-2024-27432
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix PPE hanging issue A patch to resolve an issue was found in MediaTek's GPL-licensed SDK: In the mtk_ppe_stop() function, the PPE scan mode is not disabled before disabling the PPE. This can potentially lead to a hang during the process of disabling the PPE. Without this patch, the PPE may experience a hang during the reboot test. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk_eth_soc: soluciona el problema de bloqueo del PPE Se encontró un parche para resolver un problema en el SDK con licencia GPL de MediaTek: En la función mtk_ppe_stop(), el modo de escaneo del PPE no está desactivado antes de desactivar el EPI. Potencialmente, esto puede provocar un bloqueo durante el proceso de desactivación del EPI. Sin este parche, el PPE puede sufrir un bloqueo durante la prueba de reinicio. • https://git.kernel.org/stable/c/ba37b7caf1ed2395cc84d8f823ff933975f1f789 https://git.kernel.org/stable/c/9fcadd125044007351905d40c405fadc2d3bb6d6 https://git.kernel.org/stable/c/f78807362828ad01db2a9ed005bf79501b620f27 https://git.kernel.org/stable/c/943c14ece95eb1cf98d477462aebcbfdfd714633 https://git.kernel.org/stable/c/49202a8256fc50517ef06fd5e2084c4febde6369 https://git.kernel.org/stable/c/09a1907433865b7c8ee6777e507f5126bdd38c0f https://git.kernel.org/stable/c/ea80e3ed09ab2c2b75724faf5484721753e92c31 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52660 – media: rkisp1: Fix IRQ handling due to shared interrupts
https://notcve.org/view.php?id=CVE-2023-52660
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ handling due to shared interrupts The driver requests the interrupts as IRQF_SHARED, so the interrupt handlers can be called at any time. If such a call happens while the ISP is powered down, the SoC will hang as the driver tries to access the ISP registers. This can be reproduced even without the platform sharing the IRQ line: Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will hang. Fix this by adding a new field, 'irqs_enabled', which is used to bail out from the interrupt handler when the ISP is not operational. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: rkisp1: Corrige el manejo de IRQ debido a interrupciones compartidas. El controlador solicita las interrupciones como IRQF_SHARED, por lo que se puede llamar a los controladores de interrupciones en cualquier momento. Si se produce una llamada de este tipo mientras el ISP está apagado, el SoC se bloqueará cuando el controlador intente acceder a los registros del ISP. • https://git.kernel.org/stable/c/abd34206f396d3ae50cddbd5aa840b8cd7f68c63 https://git.kernel.org/stable/c/b39b4d207d4f236a74e20d291f6356f2231fd9ee https://git.kernel.org/stable/c/edcf92bc66d8361c51dff953a55210e5cfd95587 https://git.kernel.org/stable/c/ffb635bb398fc07cb38f8a7b4a82cbe5f412f08e •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52659 – x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type
https://notcve.org/view.php?id=CVE-2023-52659
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type On 64-bit platforms, the pfn_to_kaddr() macro requires that the input value is 64 bits in order to ensure that valid address bits don't get lost when shifting that input by PAGE_SHIFT to calculate the physical address to provide a virtual address for. One such example is in pvalidate_pages() (used by SEV-SNP guests), where the GFN in the struct used for page-state change requests is a 40-bit bit-field, so attempts to pass this GFN field directly into pfn_to_kaddr() ends up causing guest crashes when dealing with addresses above the 1TB range due to the above. Fix this issue with SEV-SNP guests, as well as any similar cases that might cause issues in current/future code, by using an inline function, instead of a macro, so that the input is implicitly cast to the expected 64-bit input type prior to performing the shift operation. While it might be argued that the issue is on the caller side, other archs/macros have taken similar approaches to deal with instances like this, such as ARM explicitly casting the input to phys_addr_t: e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()") A C inline function is even better though. [ mingo: Refined the changelog some more & added __always_inline. ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm: garantiza que la entrada a pfn_to_kaddr() se trate como un tipo de 64 bits. En plataformas de 64 bits, la macro pfn_to_kaddr() requiere que el valor de entrada sea de 64 bits en para garantizar que los bits de dirección válidos no se pierdan al cambiar esa entrada mediante PAGE_SHIFT para calcular la dirección física para la que proporcionar una dirección virtual. Un ejemplo de ello es pvalidate_pages() (utilizado por invitados SEV-SNP), donde el GFN en la estructura utilizada para las solicitudes de cambio de estado de página es un campo de bits de 40 bits, por lo que se intenta pasar este campo GFN directamente a pfn_to_kaddr( ) termina causando fallas en los invitados cuando se trata de direcciones por encima del rango de 1 TB debido a lo anterior. Solucione este problema con los invitados SEV-SNP, así como cualquier caso similar que pueda causar problemas en el código actual/futuro, utilizando una función en línea, en lugar de una macro, de modo que la entrada se convierta implícitamente a la entrada esperada de 64 bits. tipo antes de realizar la operación de cambio. Si bien se podría argumentar que el problema está en el lado de la persona que llama, otros arcos/macros han adoptado enfoques similares para lidiar con casos como este, como ARM que envía explícitamente la entrada a phys_addr_t: e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()") La función en línea AC es aún mejor. • https://git.kernel.org/stable/c/6c3211796326a9d35618b866826ca556c8f008a8 https://git.kernel.org/stable/c/325956b0173f11e98f90462be4829a8b8b0682ce https://git.kernel.org/stable/c/7e1471888a5e6e846e9b4d306e5327db2b58e64e https://git.kernel.org/stable/c/814305b5c23cb815ada68d43019f39050472b25f https://git.kernel.org/stable/c/8e5647a723c49d73b9f108a8bb38e8c29d3948ea https://access.redhat.com/security/cve/CVE-2023-52659 https://bugzilla.redhat.com/show_bug.cgi?id=2281145 •