CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50152 – smb: client: fix possible double free in smb2_set_ea()
https://notcve.org/view.php?id=CVE-2024-50152
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix possible double free in smb2_set_ea() Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~ There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto sea_exit' -> 'first memory release for ea' -> 'goto replay_again' -> 'second goto sea_exit before allocate memory for ea' -> 'second memory release for ea resulted in double free'. Re-initialie 'ea' to NULL near to the replay_again label, it can fix this double free problem. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige una posible doble liberación en smb2_set_ea() Advertencia del comprobador estático de Clang (scan-build): fs/smb/client/smb2ops.c:1304:2: Intento de liberar memoria liberada. 1304 | kfree(ea); | ^~~~~~~~~ Hay una doble liberación en tal caso: 'ea se inicializa a NULL' -> 'primera asignación de memoria exitosa para ea' -> 'algo falló, goto sea_exit' -> 'primera liberación de memoria para ea' -> 'goto replay_again' -> 'segundo goto sea_exit antes de asignar memoria para ea' -> 'la segunda liberación de memoria para ea resultó en una doble liberación'. Reinicialice 'ea' a NULL cerca de la etiqueta replay_again, puede solucionar este problema de doble liberación. • https://git.kernel.org/stable/c/433042a91f9373241307725b52de573933ffedbf https://git.kernel.org/stable/c/4f1fffa2376922f3d1d506e49c0fd445b023a28e https://git.kernel.org/stable/c/b1813c220b76f60b1727984794377c4aa849d4c1 https://git.kernel.org/stable/c/c9f758ecf2562dfdd4adf12c22921b5de8366123 https://git.kernel.org/stable/c/19ebc1e6cab334a8193398d4152deb76019b5d34 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50151 – smb: client: fix OOBs when building SMB2_IOCTL request
https://notcve.org/view.php?id=CVE-2024-50151
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? • https://git.kernel.org/stable/c/e77fe73c7e38c36145825d84cfe385d400aba4fd https://git.kernel.org/stable/c/6f0516ef1290da24b85461ed08a0938af7415e49 https://git.kernel.org/stable/c/ed31aba8ce93472d9e16f5cff844ae7c94e9601d https://git.kernel.org/stable/c/e07d05b7f5ad9a503d9cab0afde2ab867bb65470 https://git.kernel.org/stable/c/2ef632bfb888d1a14f81c1703817951e0bec5531 https://git.kernel.org/stable/c/b209c3a0bc3ac172265c7fa8309e5d00654f2510 https://git.kernel.org/stable/c/fe92ddc1c32d4474e605e3a31a4afcd0e7d765ec https://git.kernel.org/stable/c/1ab60323c5201bef25f2a3dc0ccc404d9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50150 – usb: typec: altmode should keep reference to parent
https://notcve.org/view.php?id=CVE-2024-50150
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? • https://git.kernel.org/stable/c/8a37d87d72f0c69f837229c04d2fcd7117ea57e7 https://git.kernel.org/stable/c/2b0b33e8a58388fa9078f0fbe9af1900e6b08879 https://git.kernel.org/stable/c/2c15c4133d00f5da632fce60ed013fc31aa9aa58 https://git.kernel.org/stable/c/6af43ec3bf40f8b428d9134ffa7a291aecd60da8 https://git.kernel.org/stable/c/87474406056891e4fdea0794e1f632b21b3dfa27 https://git.kernel.org/stable/c/bee1b68cb8bcee4fd3a8bde3a4886e0b1375dc4d https://git.kernel.org/stable/c/1ded6b12499e6dee9b0e1ceac633be36538f6fc2 https://git.kernel.org/stable/c/68a7c7fe322546be1464174c8d85874b8 •
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: 4EXPL: 0CVE-2024-50147 – net/mlx5: Fix command bitmask initialization
https://notcve.org/view.php?id=CVE-2024-50147
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix command bitmask initialization Command bitmask have a dedicated bit for MANAGE_PAGES command, this bit isn't Initialize during command bitmask Initialization, only during MANAGE_PAGES. In addition, mlx5_cmd_trigger_completions() is trying to trigger completion for MANAGE_PAGES command as well. Hence, in case health error occurred before any MANAGE_PAGES command have been invoke (for example, during mlx5_enable_hca()), mlx5_cmd_trigger_completions() will try to trigger completion for MANAGE_PAGES command, which will result in null-ptr-deref error.[1] Fix it by Initialize command bitmask correctly. While at it, re-write the code for better understanding. [1] BUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] Write of size 4 at addr 0000000000000214 by task kworker/u96:2/12078 CPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 kasan_report+0xb9/0xf0 kasan_check_range+0xec/0x190 mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core] mlx5_cmd_flush+0x94/0x240 [mlx5_core] enter_error_state+0x6c/0xd0 [mlx5_core] mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core] process_one_work+0x787/0x1490 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x586/0xd30 ? rescuer_thread+0xae0/0xae0 kthread+0x2df/0x3b0 ? • https://git.kernel.org/stable/c/9b98d395b85dd042fe83fb696b1ac02e6c93a520 https://git.kernel.org/stable/c/d1606090bb294cecb7de3c4ed177f5aa0abd4c4e https://git.kernel.org/stable/c/d88564c79d1cedaf2655f12261eca0d2796bde4e https://git.kernel.org/stable/c/2feac1e562be0efc621a6722644a90f355d53473 https://git.kernel.org/stable/c/d62b14045c6511a7b2d4948d1a83a4e592deeb05 •