Page 363 of 2049 results (0.007 seconds)

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix incorrect usage for sb_index Commit d7038f951828 ("md-bitmap: don't use ->index for pages backing the bitmap file") removed page->index from bitmap code, but left wrong code logic for clustered-md. current code never set slot offset for cluster nodes, will sometimes cause crash in clustered env. Call trace (partly): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_mod] md_submit_bio+0x80/0xf8 [md_mod] __submit_bio+0x178/0x300 submit_bio_noacct_nocheck+0x11c/0x338 submit_bio_noacct+0x134/0x614 submit_bio+0x28/0xdc submit_bh_wbc+0x130/0x1cc submit_bh+0x1c/0x28 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/md-bitmap: corrige el uso incorrecto de sb_index Commit d7038f951828 ("md-bitmap: no usar ->índice para páginas que respaldan el archivo de mapa de bits") página eliminada-> índice del código de mapa de bits, pero dejó una lógica de código incorrecta para clustered-md. El código actual nunca establece el desplazamiento de ranura para los nodos del clúster, a veces causa fallos en el entorno del clúster. Rastreo de llamadas (parcialmente): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_submit_bio+0x8 0/0xf8 [md_mod] __submit_bio+0x178/ 0x300 enviar_bio_noacct_nocheck+0x11c/0x338 enviar_bio_noacct+0x134/0x614 enviar_bio+0x28/0xdc enviar_bh_wbc+0x130/0x1cc enviar_bh+0x1c/0x28 • https://git.kernel.org/stable/c/d7038f951828da19fa9aafddfa087b69032c9687 https://git.kernel.org/stable/c/736ad6c577a367834118f57417038d45bb5e0a31 https://git.kernel.org/stable/c/55e55eb65fd5e09faf5a0e49ffcdd37905aaf4da https://git.kernel.org/stable/c/5a95815b17428ce2f56ec18da5e0d1b2a1a15240 https://git.kernel.org/stable/c/ecbd8ebb51bf7e4939d83b9e6022a55cac44ef06 https://access.redhat.com/security/cve/CVE-2024-35787 https://bugzilla.redhat.com/show_bug.cgi?id=2281061 •

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Stop parsing channels bits when all channels are found. If a usb audio device sets more bits than the amount of channels it could write outside of the map array. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: deja de analizar bits de canales cuando se encuentran todos los canales. Si un dispositivo de audio USB establece más bits que la cantidad de canales, podría escribir fuera de la matriz del mapa. • https://git.kernel.org/stable/c/04324ccc75f96b3ed7aad1c866d1b7925e977bdf https://git.kernel.org/stable/c/7e2c1b0f6dd9abde9e60f0f9730026714468770f https://git.kernel.org/stable/c/6d5dc96b154be371df0d62ecb07efe400701ed8a https://git.kernel.org/stable/c/5cd466673b34bac369334f66cbe14bb77b7d7827 https://git.kernel.org/stable/c/9af1658ba293458ca6a13f70637b9654fa4be064 https://git.kernel.org/stable/c/629af0d5fe94a35f498ba2c3f19bd78bfa591be6 https://git.kernel.org/stable/c/22cad1b841a63635a38273b799b4791f202ade72 https://git.kernel.org/stable/c/c8a24fd281dcdf3c926413dafbafcf35c • CWE-787: Out-of-bounds Write •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: nvme: fix reconnection fail due to reserved tag allocation We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue. • https://git.kernel.org/stable/c/ed01fee283a067c72b2d6500046080dbc1bb9dae https://git.kernel.org/stable/c/149afee5c7418ec5db9d7387b9c9a5c1eb7ea2a8 https://git.kernel.org/stable/c/ff2f90f88d78559802466ad1c84ac5bda4416b3a https://git.kernel.org/stable/c/6851778504cdb49431809b4ba061903d5f592c96 https://git.kernel.org/stable/c/262da920896e2f2ab0e3947d9dbee0aa09045818 https://git.kernel.org/stable/c/de105068fead55ed5c07ade75e9c8e7f86a00d1d https://access.redhat.com/security/cve/CVE-2024-27435 https://bugzilla.redhat.com/show_bug.cgi?id=2281131 •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

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: 0

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 •