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: 4EXPL: 0CVE-2024-50145 – octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()
https://notcve.org/view.php?id=CVE-2024-50145
In the Linux kernel, the following vulnerability has been resolved: octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx() build_skb() returns NULL in case of a memory allocation failure so handle it inside __octep_oq_process_rx() to avoid NULL pointer dereference. __octep_oq_process_rx() is called during NAPI polling by the driver. If skb allocation fails, keep on pulling packets out of the Rx DMA queue: we shouldn't break the polling immediately and thus falsely indicate to the octep_napi_poll() that the Rx pressure is going down. As there is no associated skb in this case, don't process the packets and don't push them up the network stack - they are skipped. Helper function is implemented to unmmap/flush all the fragment buffers used by the dropped packet. 'alloc_failures' counter is incremented to mark the skb allocation error in driver statistics. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeon_ep: Agregar manejo de fallas de asignación de SKB en __octep_oq_process_rx() build_skb() devuelve NULL en caso de una falla de asignación de memoria, por lo que se maneja dentro de __octep_oq_process_rx() para evitar la desreferencia del puntero NULL. • https://git.kernel.org/stable/c/37d79d0596062057f588bdbb2ebad5455a43d353 https://git.kernel.org/stable/c/09ce491112bbf0b866e2638d3e961c1c73d1f00b https://git.kernel.org/stable/c/c2d2dc4f88bb3cfc4f3cc320fd3ff51b0ae5b0ea https://git.kernel.org/stable/c/2dedcb6f99f4c1a11944e7cc35dbeb9b18a5cbac https://git.kernel.org/stable/c/eb592008f79be52ccef88cd9a5249b3fc0367278 •
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 •