CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50142 – xfrm: validate new SA's prefixlen using SA family when sel.family is unset
https://notcve.org/view.php?id=CVE-2024-50142
In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: validar el prefijo de la nueva SA usando la familia de SA cuando sel.family no está configurado Esto expande la validación introducida en el commit 07bf7908950a ("xfrm: validar las longitudes de prefijo de dirección en el selector xfrm"). syzbot creó una SA con usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Debido al selector AF_UNSPEC, verificar_newsa_info no pone límites en prefixlen_{s,d}. Pero luego copy_from_user_state establece x->sel.family en usersa.family (AF_INET). • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/f31398570acf0f0804c644006f7bfa9067106b0a https://git.kernel.org/stable/c/401ad99a5ae7180dd9449eac104cb755f442e7f3 https://git.kernel.org/stable/c/8df5cd51fd70c33aa1776e5cbcd82b0a86649d73 https://git.kernel.org/stable/c/2d08a6c31c65f23db71a5385ee9cf9d8f9a67a71 https://git.kernel.org/stable/c/bce1afaa212ec380bf971614f70909a27882b862 https://git.kernel.org/stable/c/7d9868180bd1e4cf37e7c5067362658971162366 https://git.kernel.org/stable/c/e68dd80ba498265d2266b12dc3459164f •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50134 – drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA
https://notcve.org/view.php?id=CVE-2024-50134
In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vboxvideo: Reemplazar VLA falso al final de vbva_mouse_pointer_shape con VLA real Reemplace el VLA falso al final de la forma vbva_mouse_pointer_shape con un VLA real para corregir una advertencia "memcpy: error de escritura que abarca el campo detectado": [ 13.319813] memcpy: se detectó una escritura que abarca el campo (tamaño 16896) de un solo campo "p->data" en drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (tamaño 4) [ 13.319841] ADVERTENCIA: CPU: 0 PID: 1105 en drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ [13.320038] Seguimiento de llamadas: [13.320173] hgsmi_update_pointer_shape [vboxvideo] [13.320184] vbox_cursor_atomic_update [vboxvideo] Tenga en cuenta que, como se menciona en el comentario agregado, parece que el cálculo de longitud original para el búfer hgsmi asignado y enviado es 4 bytes más grande. Cambiar esto no es el objetivo de este parche, por lo que se mantiene este comportamiento. • https://git.kernel.org/stable/c/02c86c5d5ef4bbba17d38859c74872825f536617 https://git.kernel.org/stable/c/75f828e944dacaac8870418461d3d48a1ecf2331 https://git.kernel.org/stable/c/34a422274b693507025a7db21519865d1862afcb https://git.kernel.org/stable/c/7458a6cdaebb3dc59af8578ee354fae78a154c4a https://git.kernel.org/stable/c/9eb32bd23bbcec44bcbef27b7f282b7a7f3d0391 https://git.kernel.org/stable/c/fae9dc12c61ce23cf29d09824a741b7b1ff8f01f https://git.kernel.org/stable/c/d92b90f9a54d9300a6e883258e79f36dab53bfae •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50115 – KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
https://notcve.org/view.php?id=CVE-2024-50115
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: nSVM: Ignorar nCR3[4:0] al cargar PDPTE desde la memoria Ignorar nCR3[4:0] al cargar PDPTE desde la memoria para SVM anidado, ya que los bits 4:0 de CR3 se ignoran cuando se utiliza la paginación PAE y, por lo tanto, VMRUN no aplica la alineación de 32 bytes de nCR3. En el peor de los casos, no ignorar los bits 4:0 puede dar como resultado una lectura fuera de los límites, por ejemplo, si la página de destino está al final de un memslot y el VMM no está utilizando páginas de protección. Según el APM: El registro CR3 apunta a la dirección base de la tabla de punteros de directorio de páginas. • https://git.kernel.org/stable/c/e4e517b4be019787ada4cbbce2f04570c21b0cbd https://git.kernel.org/stable/c/76ce386feb14ec9a460784fcd495d8432acce7a5 https://git.kernel.org/stable/c/58cb697d80e669c56197f703e188867c8c54c494 https://git.kernel.org/stable/c/6876793907cbe19d42e9edc8c3315a21e06c32ae https://git.kernel.org/stable/c/2c4adc9b192a0815fe58a62bc0709449416cc884 https://git.kernel.org/stable/c/426682afec71ea3f889b972d038238807b9443e4 https://git.kernel.org/stable/c/f559b2e9c5c5308850544ab59396b7d53cfc67bd •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50112 – x86/lam: Disable ADDRESS_MASKING in most cases
https://notcve.org/view.php?id=CVE-2024-50112
In the Linux kernel, the following vulnerability has been resolved: x86/lam: Disable ADDRESS_MASKING in most cases Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in market that support LAM yet, so currently nobody is affected by this issue. [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ [ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/lam: Deshabilitar ADDRESS_MASKING en la mayoría de los casos. El enmascaramiento de direcciones lineales (LAM) tiene una debilidad relacionada con la ejecución transitoria como se describe en el documento SLAM[1]. A menos que se habilite la separación del espacio de direcciones lineales (LASS), esta debilidad puede ser explotable. Hasta que el kernel agregue soporte para LASS[2], solo permita LAM para COMPILE_TEST, o cuando las mitigaciones de especulación se hayan deshabilitado en el momento de la compilación, de lo contrario, mantenga LAM deshabilitado. • https://git.kernel.org/stable/c/60a5ba560f296ad8da153f6ad3f70030bfa3958f https://git.kernel.org/stable/c/690599066488d16db96ac0d6340f9372fc56f337 https://git.kernel.org/stable/c/3267cb6d3a174ff83d6287dcd5b0047bbd912452 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50108 – drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too
https://notcve.org/view.php?id=CVE-2024-50108
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too Stuart Hayhurst has found that both at bootup and fullscreen VA-API video is leading to black screens for around 1 second and kernel WARNING [1] traces when calling dmub_psr_enable() with Parade 08-01 TCON. These symptoms all go away with PSR-SU disabled for this TCON, so disable it for now while DMUB traces [2] from the failure can be analyzed and the failure state properly root caused. (cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Deshabilitar PSR-SU también en Parade 08-01 TCON Stuart Hayhurst ha descubierto que tanto en el arranque como en pantalla completa, el vídeo VA-API provoca pantallas negras durante alrededor de 1 segundo y rastros de ADVERTENCIA [1] en el kernel al llamar a dmub_psr_enable() con Parade 08-01 TCON. Todos estos síntomas desaparecen con PSR-SU deshabilitado para este TCON, así que deshabilítelo por ahora mientras se pueden analizar los rastros DMUB [2] del fallo y se puede determinar correctamente el estado del fallo. (seleccionado de la confirmación afb634a6823d8d9db23c5fb04f79c5549349628b) • https://git.kernel.org/stable/c/5660bcc4dd533005248577d5042f1c48cce2b443 https://git.kernel.org/stable/c/c79e0a18e4b301401bb745702830be9041cfbf04 https://git.kernel.org/stable/c/fc6afa07b5e251148fb37600ee06e1a7007178c3 https://git.kernel.org/stable/c/ba1959f71117b27f3099ee789e0815360b4081dd •