CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50153 – scsi: target: core: Fix null-ptr-deref in target_alloc_device()
https://notcve.org/view.php?id=CVE-2024-50153
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: core: Corregir null-ptr-deref en target_alloc_device() KASAN ha informado de un problema de null-ptr-deref: ERROR: KASAN: null-ptr-deref en target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e En target_alloc_device(), si falla la asignación de memoria para las colas dev, dev se liberará mediante dev->transport->free_device(), pero dev->transport no se inicializa en ese momento, lo que generará un problema de referencia de puntero nulo. Se soluciona este error liberando dev con hba->backend->ops->free_device(). • https://git.kernel.org/stable/c/008b936bbde3e87a611b3828a0d5d2a4f99026a0 https://git.kernel.org/stable/c/1526d9f10c6184031e42afad0adbdde1213e8ad1 https://git.kernel.org/stable/c/8c1e6717f60d31f8af3937c23c4f1498529584e1 https://git.kernel.org/stable/c/39e02fa90323243187c91bb3e8f2f5f6a9aacfc7 https://git.kernel.org/stable/c/895ab729425ef9bf3b6d2f8d0853abe64896f314 https://git.kernel.org/stable/c/b80e9bc85bd9af378e7eac83e15dd129557bbdb6 https://git.kernel.org/stable/c/14a6a2adb440e4ae97bee73b2360946bd033dadd https://git.kernel.org/stable/c/fca6caeb4a61d240f031914413fcc6953 •
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 •