CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26715 – usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend
https://notcve.org/view.php?id=CVE-2024-26715
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: corrige la desreferencia del puntero NULL en dwc3_gadget_suspend En el escenario actual, si el Plug-out y el Plug-In se ejecutan continuamente, podría haber una posibilidad al verificar dwc->gadget_driver en dwc3_gadget_suspend, puede ocurrir una desreferencia del puntero NULL. Pila de llamadas: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 básicamente borra la variable y CPU2 verifica la variable. Considere que CPU1 se está ejecutando y justo antes de que se borre gadget_driver y en paralelo CPU2 ejecuta dwc3_gadget_suspend donde encuentra dwc->gadget_driver que no es NULL y reanuda la ejecución y luego CPU1 completa la ejecución. • https://git.kernel.org/stable/c/9772b47a4c2916d645c551228b6085ea24acbe5d https://git.kernel.org/stable/c/8cca5c85393a7a490d4d7942c24d73d29cc77b3e https://git.kernel.org/stable/c/df2ca3271569367352835f981618e284fdc4ca94 https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7 https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751 https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182 https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26714 – interconnect: qcom: sc8180x: Mark CO0 BCM keepalive
https://notcve.org/view.php?id=CVE-2024-26714
In the Linux kernel, the following vulnerability has been resolved: interconnect: qcom: sc8180x: Mark CO0 BCM keepalive The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexión: qcom: sc8180x: Mark CO0 BCM keepalive El CO0 BCM debe estar activo en todo momento; de lo contrario, algún hardware (como el controlador UFS) pierde su conexión con el resto del SoC, lo que provocó un bloqueo de la plataforma, acompañado de un espectacular logspam. Márquelo como keepalive para evitar tales casos. • https://git.kernel.org/stable/c/9c8c6bac1ae86f6902baa938101902fb3a0a100b https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7 https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43 https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0 https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26713 – powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add
https://notcve.org/view.php?id=CVE-2024-26713
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add When a PCI device is dynamically added, the kernel oopses with a NULL pointer dereference: BUG: Kernel NULL pointer dereference on read at 0x00000030 Faulting instruction address: 0xc0000000006bbe5c Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24002220 XER: 20040006 CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0 ... NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Call Trace: iommu_init_device+0x26c/0x318 (unreliable) iommu_device_link+0x5c/0x118 iommu_init_device+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+0x44/0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_scan_pci_dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+0xb8/0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec Commit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains") broke DLPAR add of PCI devices. The above added iommu_device structure to pci_controller. During system boot, PCI devices are discovered and this newly added iommu_device structure is initialized by a call to iommu_device_register(). During DLPAR add of a PCI device, a new pci_controller structure is allocated but there are no calls made to iommu_device_register() interface. Fix is to register the iommu device during DLPAR add as well. [mpe: Trim oops and tweak some change log wording] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries/iommu: corrige la inicialización de iommu durante la adición de DLPAR Cuando se agrega dinámicamente un dispositivo PCI, el kernel falla con una desreferencia del puntero NULL: ERROR: desreferencia del puntero NULL del kernel al leer en 0x00000030 Dirección de instrucción errónea: 0xc0000000006bbe5c Vaya: acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Módulos vinculados en: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcg ss nfsv4 dns_resolver nfs lockd gracia fscache netfs xsk_diag vinculación nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fusible CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66 Nombre de hardware: IBM,9080-HEX POWER10 (sin formato) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8 REGS: c00000009924f240 TRAP: 0300 No contaminado (6.7.0-203405+) MSR: 80000000000009033 CR: 24002220 XER: 20040006 CF AR: c000000000a13e64 DAR: 0000000000000030DSISR : 40000000 IRQMASK: 0 ... NIP sysfs_add_link_to_group+0x34/0x94 LR iommu_device_link+0x5c/0x118 Rastreo de llamadas: iommu_init_device+0x26c/0x318 (no confiable) iommu_device_link+0x5c/0x118 iommu_init_ dispositivo+0xa8/0x318 iommu_probe_device+0xc0/0x134 iommu_bus_notifier+0x44/ 0x104 notifier_call_chain+0xb8/0x19c blocking_notifier_call_chain+0x64/0x98 bus_notify+0x50/0x7c device_add+0x640/0x918 pci_device_add+0x23c/0x298 of_create_pci_dev+0x400/0x884 of_scan_pci_ dev+0x124/0x1b0 __of_scan_bus+0x78/0x18c pcibios_scan_phb+0x2a4/0x3b0 init_phb_dynamic+0xb8/ 0x110 dlpar_add_slot+0x170/0x3b8 [rpadlpar_io] add_slot_store.part.0+0xb4/0x130 [rpadlpar_io] kobj_attr_store+0x2c/0x48 sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x2 90 vfs_write+0x350/0x4a0 ksys_write+0x84/0x140 system_call_exception+0x124/ 0x330 system_call_vectored_common+0x15c/0x2ec el commit a940904443e4 ("powerpc/iommu: agregue iommu_ops para informar capacidades y permitir dominios de bloqueo") rompió la adición DLPAR de dispositivos PCI. Lo anterior agregó la estructura iommu_device a pci_controller. Durante el arranque del SYSTEM, se descubren dispositivos PCI y esta estructura iommu_device recién agregada se inicializa mediante una llamada a iommu_device_register(). • https://git.kernel.org/stable/c/a940904443e432623579245babe63e2486ff327b https://git.kernel.org/stable/c/9978d5b744e0227afe19e3bcb4c5f75442dde753 https://git.kernel.org/stable/c/d4f762d6403f7419de90d7749fa83dd92ffb0e1d https://git.kernel.org/stable/c/ed8b94f6e0acd652ce69bd69d678a0c769172df8 •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26712 – powerpc/kasan: Fix addr error caused by page alignment
https://notcve.org/view.php?id=CVE-2024-26712
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/kasan: corrige el error de dirección causado por la alineación de la página En kasan_init_region, cuando k_start no está alineado con la página, al comienzo del bucle for, k_cur = k_start y PAGE_MASK es menor que k_start. y luego `va = block + k_cur - k_start` es menor que block, la dirección va no es válida, porque memblock_alloc no asigna el espacio de direcciones de memoria de va al bloque, que no será reservado por memblock_reserve más adelante, se utilizará por otros lugares. Como resultado, se produce una sobrescritura de la memoria. por ejemplo: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* al comienzo del bucle for * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va (dcd96c00) es menor que block(dcd97000), va no es válido */ void *va = block + k_cur - k_start; [...] } [...] } Por lo tanto, la alineación de la página se realiza en k_start antes de memblock_alloc() para garantizar la validez de la dirección VA. • https://git.kernel.org/stable/c/663c0c9496a69f80011205ba3194049bcafd681d https://git.kernel.org/stable/c/5ce93076d8ee2a0fac3ad4adbd2e91b6197146db https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882 https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6 https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058 https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25 https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49 • CWE-20: Improper Input Validation •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26711 – iio: adc: ad4130: zero-initialize clock init data
https://notcve.org/view.php?id=CVE-2024-26711
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad4130: zero-initialize clock init data The clk_init_data struct does not have all its members initialized, causing issues when trying to expose the internal clock on the CLK pin. Fix this by zero-initializing the clk_init_data struct. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: adc: ad4130: datos de inicio de reloj con inicialización cero La estructura clk_init_data no tiene todos sus miembros inicializados, lo que causa problemas al intentar exponer el reloj interno en el pin CLK. Solucione este problema inicializando a cero la estructura clk_init_data. • https://git.kernel.org/stable/c/62094060cf3acaf52e277457d807ea753269b89e https://git.kernel.org/stable/c/0e0dab37750926d4fb0144edb1c1ea0612fea273 https://git.kernel.org/stable/c/02876e2df02f8b17a593d77a0a7879a8109b27e1 https://git.kernel.org/stable/c/a22b0a2be69a36511cb5b37d948b651ddf7debf3 •