CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39487 – bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
https://notcve.org/view.php?id=CVE-2024-39487
In the Linux kernel, the following vulnerability has been resolved: bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bonding: corrige la lectura fuera de los límites en bond_option_arp_ip_targets_set() En la función bond_option_arp_ip_targets_set(), si newval->string es una cadena vacía, newval->string+1 apuntará a el byte después de la cadena, lo que provoca una lectura fuera de los límites. ERROR: KASAN: slab-out-of-bounds en strlen+0x7d/0xa0 lib/string.c:418 Lectura del tamaño 1 en la dirección ffff8881119c4781 por tarea syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 No tainted 6.7.0-rc7 #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [en línea] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report. c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [en línea] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 controladores /net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 controladores/net/bonding/bond_options.c: 767 __bond_opt_set_notify+0x48/0x150 Drivers/net/bonding/bond_options.c: 792 bond_pt_tryset neto /bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c :136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x96a/0xd80 fs/read_write.c :584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6 ---[rastreo final]--- Solucionelo agregando una verificación de la longitud de la cadena antes de usarlo. • https://git.kernel.org/stable/c/f9de11a165943a55e0fbda714caf60eaeb276a42 https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1 https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9 https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8 https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7a •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39486 – drm/drm_file: Fix pid refcounting race
https://notcve.org/view.php?id=CVE-2024-39486
In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de> filp->pid is supposed to be a refcounted pointer; however, before this patch, drm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelist_mutex, making the following race possible: process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>) As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler. This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronize_rcu() operation while process B is between mutex_unlock() and get_pid(). Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken. This fix also removes the condition for synchronize_rcu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drm_file: corrige la ejecución de recuento de pid filp->pid se supone que es un puntero recontado; sin embargo, antes de este parche, drm_file_update_pid() solo incrementa el recuento de una estructura pid después de almacenar un puntero a ella en filp->pid y eliminar dev->filelist_mutex, haciendo posible la siguiente ejecución: proceso A proceso B ==== ===== ========= comenzar drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev- >filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) get_pid() synchronize_rcu() put_pid() *** pid B alcanza refcount 0 y se libera aquí *** get_pid() *** UAF *** synchronize_rcu() put_pid() Hasta donde yo sé, esta ejecución solo puede ocurrir con CONFIG_PREEMPT_RCU=y porque requiere que RCU detecte un estado inactivo en el código que no llame explícitamente al programador. Esta ejecución conduce a use after free de una "estructura pid". Probablemente sea algo difícil de lograr porque el proceso A tiene que pasar por una operación synchronize_rcu() mientras que el proceso B está entre mutex_unlock() y get_pid(). Solucionelo asegurándose de que cuando se almacene en el archivo un puntero al pid de la tarea actual, se haya tomado una referencia adicional al pid. • https://git.kernel.org/stable/c/031ddd28008971cce0b5626379b910d0a05fb4dd https://git.kernel.org/stable/c/1c7a387ffef894b1ab3942f0482dac7a6e0a909c https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39485 – media: v4l: async: Properly re-initialise notifier entry in unregister
https://notcve.org/view.php?id=CVE-2024-39485
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Properly re-initialise notifier entry in unregister The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: v4l: async: Reinicializar correctamente la entrada del notificador al cancelar el registro Notifier_entry de un notificador no se reinicializa después de cancelar el registro del notificador. Esto lleva a que se dejen punteros colgando allí, así que use list_del_init() para devolver notifier_entry una lista vacía. • https://git.kernel.org/stable/c/b8ec754ae4c563f6aab8c0cb47aeb2eae67f1da3 https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66 https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a • CWE-665: Improper Initialization •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-39484 – mmc: davinci: Don't strip remove function when driver is builtin
https://notcve.org/view.php?id=CVE-2024-39484
In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: davinci: no eliminar la función de eliminación cuando el controlador está integrado. El uso de __exit para la función de eliminación hace que la devolución de llamada de eliminación se descarte con CONFIG_MMC_DAVINCI=y. • https://git.kernel.org/stable/c/b4cff4549b7a8c5fc8b88e3493b6287555f0512c https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4 https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1 https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584 https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39483 – KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked
https://notcve.org/view.php?id=CVE-2024-39483
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. • https://git.kernel.org/stable/c/fa4c027a7956f5e07697bfcb580d25eeb8471257 https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356 https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1 https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6 •