CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50144 – drm/xe: fix unbalanced rpm put() with fence_fini()
https://notcve.org/view.php?id=CVE-2024-50144
In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix unbalanced rpm put() with fence_fini() Currently we can call fence_fini() twice if something goes wrong when sending the GuC CT for the tlb request, since we signal the fence and return an error, leading to the caller also calling fini() on the error path in the case of stack version of the flow, which leads to an extra rpm put() which might later cause device to enter suspend when it shouldn't. It looks like we can just drop the fini() call since the fence signaller side will already call this for us. There are known mysterious splats with device going to sleep even with an rpm ref, and this could be one candidate. v2 (Matt B): - Prefer warning if we detect double fini() (cherry picked from commit cfcbc0520d5055825f0647ab922b655688605183) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: corregir rpm put() desequilibrado con fence_fini() Actualmente podemos llamar a fence_fini() dos veces si algo sale mal al enviar el GuC CT para la solicitud tlb, ya que señalamos a fence y devolvemos un error, lo que lleva a que el llamador también llame a fini() en la ruta de error en el caso de la versión de pila del flujo, lo que lleva a un rpm put() adicional que más tarde podría hacer que el dispositivo entre en suspensión cuando no debería. Parece que podemos simplemente descartar la llamada a fini() ya que el lado del señalizador de fence ya lo llamará por nosotros. Hay splats misteriosos conocidos con el dispositivo entrando en suspensión incluso con una referencia rpm, y este podría ser un candidato. v2 (Matt B): - Preferimos advertencia si detectamos fini() doble (seleccionado de el commit cfcbc0520d5055825f0647ab922b655688605183) • https://git.kernel.org/stable/c/f002702290fccbd473f5bb94e52f25c96917fff2 https://git.kernel.org/stable/c/046bd018c0123b1a49c22abed5f9ea31d1454c78 https://git.kernel.org/stable/c/03a86c24aea0920a1ca20a0d7771d5e176db538d •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50143 – udf: fix uninit-value use in udf_get_fileshortad
https://notcve.org/view.php?id=CVE-2024-50143
In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: se corrige el uso de un valor no inicializado en udf_get_fileshortad. Se comprueba si hay desbordamiento al calcular alen en udf_current_aext para mitigar el uso posterior de un valor no inicializado en udf_get_fileshortad. Error de KMSAN[1]. • https://git.kernel.org/stable/c/5eb76fb98b3335aa5cca6a7db2e659561c79c32b https://git.kernel.org/stable/c/417bd613bdbe791549f7687bb1b9b8012ff111c2 https://git.kernel.org/stable/c/4fc0d8660e391dcd8dde23c44d702be1f6846c61 https://git.kernel.org/stable/c/72e445df65a0aa9066c6fe2b8736ba2fcca6dac7 https://git.kernel.org/stable/c/1ac49babc952f48d82676979b20885e480e69be8 https://git.kernel.org/stable/c/e52e0b92ed31dc62afbda15c243dcee0bb5bb58d https://git.kernel.org/stable/c/264db9d666ad9a35075cc9ed9ec09d021580fbb1 •
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: 5EXPL: 0CVE-2024-50141 – ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context
https://notcve.org/view.php?id=CVE-2024-50141
In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: PRM: Buscar bloque EFI_MEMORY_RUNTIME para el controlador PRM y el contexto PRMT necesita encontrar el tipo correcto de bloque para traducir la asignación PA-VA para los servicios de tiempo de ejecución EFI. El problema surge porque PRMT encuentra un bloque de tipo EFI_CONVENTIONAL_MEMORY, que no es apropiado para los servicios de tiempo de ejecución como se describe en la Sección 2.2.2 (Servicios de tiempo de ejecución) de la Especificación UEFI [1]. Dado que el controlador PRM es un tipo de servicio de tiempo de ejecución, esto provoca una excepción cuando se llama al controlador PRM. [Error de firmware]: No se puede manejar la solicitud de paginación en el servicio de tiempo de ejecución de EFI ADVERTENCIA: CPU: 22 PID: 4330 en drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Rastreo de llamadas: deje que PRMT encuentre un bloque con EFI_MEMORY_RUNTIME para el controlador PRM y el contexto PRM. • https://git.kernel.org/stable/c/cefc7ca46235f01d5233e3abd4b79452af01d9e9 https://git.kernel.org/stable/c/8df52929530839e878e6912e33348b54101e3250 https://git.kernel.org/stable/c/8ce081ad842510f0e70fa6065a401660eac876d4 https://git.kernel.org/stable/c/795b080d9aa127215a5baf088a22fa09341a0126 https://git.kernel.org/stable/c/20e9fafb8bb6f545667d7916b0e81e68c0748810 https://git.kernel.org/stable/c/088984c8d54c0053fc4ae606981291d741c5924b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50140 – sched/core: Disable page allocation in task_tick_mm_cid()
https://notcve.org/view.php?id=CVE-2024-50140
In the Linux kernel, the following vulnerability has been resolved: sched/core: Disable page allocation in task_tick_mm_cid() With KASAN and PREEMPT_RT enabled, calling task_work_add() in task_tick_mm_cid() may cause the following splat. [ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, expected: 0 [ 63.696416] RCU nest depth: 1, expected: 1 This problem is caused by the following call trace. sched_tick() [ acquire rq->__lock ] -> task_tick_mm_cid() -> task_work_add() -> __kasan_record_aux_stack() -> kasan_save_stack() -> stack_depot_save_flags() -> alloc_pages_mpol_noprof() -> __alloc_pages_noprof() -> get_page_from_freelist() -> rmqueue() -> rmqueue_pcplist() -> __rmqueue_pcplist() -> rmqueue_bulk() -> rt_spin_lock() The rq lock is a raw_spinlock_t. We can't sleep while holding it. IOW, we can't call alloc_pages() in stack_depot_save_flags(). The task_tick_mm_cid() function with its task_work_add() call was introduced by commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") in v6.4 kernel. Fortunately, there is a kasan_record_aux_stack_noalloc() variant that calls stack_depot_save_flags() while not allowing it to allocate new pages. To allow task_tick_mm_cid() to use task_work without page allocation, a new TWAF_NO_ALLOC flag is added to enable calling kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack() if set. The task_tick_mm_cid() function is modified to add this new flag. The possible downside is the missing stack trace in a KASAN report due to new page allocation required when task_work_add_noallloc() is called which should be rare. • https://git.kernel.org/stable/c/223baf9d17f25e2608dbdff7232c095c1e612268 https://git.kernel.org/stable/c/509c29d0d26f68a6f6d0a05cb1a89725237e2b87 https://git.kernel.org/stable/c/ce0241ef83eed55f675376e8a3605d23de53d875 https://git.kernel.org/stable/c/73ab05aa46b02d96509cb029a8d04fca7bbde8c7 •