CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50148 – Bluetooth: bnep: fix wild-memory-access in proto_unregister
https://notcve.org/view.php?id=CVE-2024-50148
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: <TASK> __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: bnep: corrige wild-memory-access en proto_unregister Hay un problema como el siguiente: KASAN: tal vez wild-memory-access en el rango [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: GW RIP: 0010:proto_unregister+0xee/0x400 Seguimiento de llamadas: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Como bnep_init() ignora el valor de retorno de bnep_sock_init(), y bnep_sock_init() limpiará Todos los recursos. Luego, cuando se elimine el módulo bnep, se llamará a bnep_sock_cleanup() para limpiar el recurso de Sock. Para resolver el problema anterior, simplemente devuelva el valor de retorno de bnep_sock_init() en bnep_exit(). • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/e232728242c4e98fb30e4c6bedb6ba8b482b6301 https://git.kernel.org/stable/c/2c439470b23d78095a0d2f923342df58b155f669 https://git.kernel.org/stable/c/6c151aeb6dc414db8f4daf51be072e802fae6667 https://git.kernel.org/stable/c/fa58e23ea1359bd24b323916d191e2e9b4b19783 https://git.kernel.org/stable/c/03015b6329e6de42f03ec917c25c4cf944f81f66 https://git.kernel.org/stable/c/d10cd7bf574ead01fae140ce117a11bcdacbe6a8 https://git.kernel.org/stable/c/20c424bc475b2b2a6e0e2225d2aae095c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50146 – net/mlx5e: Don't call cleanup on profile rollback failure
https://notcve.org/view.php?id=CVE-2024-50146
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Don't call cleanup on profile rollback failure When profile rollback fails in mlx5e_netdev_change_profile, the netdev profile var is left set to NULL. Avoid a crash when unloading the driver by not calling profile->cleanup in such a case. This was encountered while testing, with the original trigger that the wq rescuer thread creation got interrupted (presumably due to Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by mlx5e_priv_init, the profile rollback also fails for the same reason (signal still active) so the profile is left as NULL, leading to a crash later in _mlx5e_remove. [ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12 [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 745.538222] #PF: supervisor read access in kernel mode <snipped> [ 745.551290] Call Trace: [ 745.551590] <TASK> [ 745.551866] ? __die+0x20/0x60 [ 745.552218] ? page_fault_oops+0x150/0x400 [ 745.555307] ? exc_page_fault+0x79/0x240 [ 745.555729] ? • https://git.kernel.org/stable/c/3ef14e463f6ed0218710f56b97e1a7d0448784d2 https://git.kernel.org/stable/c/3955b77494c3c7d14873b1db67e7e00c46a714db https://git.kernel.org/stable/c/4dbc1d1a9f39c3711ad2a40addca04d07d9ab5d0 •
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 •