CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50122 – PCI: Hold rescan lock while adding devices during host probe
https://notcve.org/view.php?id=CVE-2024-50122
Estos últimos deben tomar el bloqueo de rescan al agregar dispositivos o podemos terminar en un estado indefinido con dos dispositivos agregados de forma incompleta y encontrar el siguiente bloqueo al intentar eliminar el dispositivo a través de sysfs: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000000 Error interno: Oops: 0000000096000004 [#1] Rastreo de llamadas SMP: __pi_strlen+0x14/0x150 kernfs_find_ns+0x80/0x13c kernfs_remove_by_name_ns+0x54/0xf0 sysfs_remove_bin_file+0x24/0x34 pci_remove_resource_files+0x3c/0x84 pci_remove_sysfs_dev_files+0x28/0x38 pci_stop_bus_device+0x8c/0xd8 pci_stop_bus_device+0x40/0xd8 pci_stop_and_remove_bus_device_locked+0x28/0x48 remove_store+0x70/0xb0 dev_attr_store+0x20/0x38 sysfs_kf_write+0x58/0x78 kernfs_fop_write_iter+0xe8/0x184 vfs_write+0x2dc/0x308 ksys_write+0x7c/0xec • https://git.kernel.org/stable/c/4565d2652a37e438e4cd729e2a8dfeffe34c958c https://git.kernel.org/stable/c/d4f38a0e7cc94615f63cf7765ca117e5cc2773ae https://git.kernel.org/stable/c/1d59d474e1cb7d4fdf87dfaf96f44647f13ea590 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50118 – btrfs: reject ro->rw reconfiguration if there are hard ro requirements
https://notcve.org/view.php?id=CVE-2024-50118
Syzbot informa del siguiente fallo: Información de BTRFS (estado de loop0 del dispositivo MCS): deshabilitar el árbol de espacio libre Información de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de función de compatibilidad para FREE_SPACE_TREE (0x1) Información de BTRFS (estado de loop0 del dispositivo MCS): borrando el indicador de función de compatibilidad para FREE_SPACE_TREE_VALID (0x2) Vaya: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000018-0x000000000000001f] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [en línea] RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 Seguimiento de llamadas: btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 btrfs_remount_rw fs/btrfs/super.c:1309 [en línea] btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [en línea] btrfs_get_tree_subvol fs/btrfs/super.c:2079 [en línea] btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115 vfs_get_tree+0x90/0x2b0 fs/super.c:1800 do_new_mount+0x2be/0xb40 fs/namespace.c:3472 do_mount fs/namespace.c:3812 [en línea] __do_sys_mount fs/namespace.c:4020 [en línea] __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSA] Para admitir el montaje de diferentes subvolúmenes con diferentes indicadores RO/RW para las nuevas API de montaje, btrfs introdujo dos workarounds para admitir esta función: - Omitir las comprobaciones de opciones/funciones de montaje si estamos montando un subvolumen diferente - Reconfigurar el fs a RW si el montaje inicial es RO Combinando estos dos, podemos tener la siguiente secuencia: - Montar el fs ro,rescue=all,clear_cache,space_cache=v1 rescue=all marcará el fs como de solo lectura, por lo que no se borrará la caché v2. - Montar un subvolumen rw del mismo fs. • https://git.kernel.org/stable/c/f044b318675f0347ecfb88377542651ba4eb9e1f https://git.kernel.org/stable/c/23724398b55d9570f6ae79dd2ea026fff8896bf1 https://git.kernel.org/stable/c/3c36a72c1d27de6618c1c480c793d9924640f5bb •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50114 – KVM: arm64: Unregister redistributor for failed vCPU creation
https://notcve.org/view.php?id=CVE-2024-50114
Ese cambio buscó correctamente evitar una inversión de srcu v. config_lock al dividir el desmontaje de la vCPU en dos partes, una protegida por config_lock. • https://git.kernel.org/stable/c/f616506754d34bcfdbfbc7508b562e5c98461e9a https://git.kernel.org/stable/c/6bcc2890b883ba1d16b8942937750565f6e9db0d https://git.kernel.org/stable/c/ae8f8b37610269009326f4318df161206c59843e •
CVSS: 6.5EPSS: 0%CPEs: -EXPL: 0CVE-2023-29115 – Denial of Service via Web Management interface in Enel X JuiceBox
https://notcve.org/view.php?id=CVE-2023-29115
In certain conditions a request directed to the Waybox Enel X Web management application could cause a denial-of-service (e.g. reboot). • https://support-emobility.enelx.com/content/dam/enelxmobility/italia/documenti/manuali-schede-tecniche/Waybox-3-Security-Bulletin-06-2024-V1.pdf • CWE-284: Improper Access Control •
CVSS: 3.3EPSS: 0%CPEs: -EXPL: 0CVE-2024-47402 – Liteos_a has an Out-of-bounds Read vulnerability
https://notcve.org/view.php?id=CVE-2024-47402
in OpenHarmony v4.0.0 and prior versions allow a local attacker cause DOS through out-of-bounds read. • https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-11.md • CWE-125: Out-of-bounds Read •