CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50104 – ASoC: qcom: sdm845: add missing soundwire runtime stream alloc
https://notcve.org/view.php?id=CVE-2024-50104
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: sdm845: add missing soundwire runtime stream alloc During the migration of Soundwire runtime stream allocation from the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845 soundcard was forgotten. At this point any playback attempt or audio daemon startup, for instance on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ... CPU: 5 UID: 0 PID: 1198 Comm: aplay Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18 Hardware name: Thundercomm Dragonboard 845c (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus] lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus] sp : ffff80008a2035c0 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8 Call trace: sdw_stream_add_slave+0x44/0x380 [soundwire_bus] wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x] snd_soc_dai_hw_params+0x3c/0xa4 __soc_pcm_hw_params+0x230/0x660 dpcm_be_dai_hw_params+0x1d0/0x3f8 dpcm_fe_dai_hw_params+0x98/0x268 snd_pcm_hw_params+0x124/0x460 snd_pcm_common_ioctl+0x998/0x16e8 snd_pcm_ioctl+0x34/0x58 __arm64_sys_ioctl+0xac/0xf8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xe0 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22) ---[ end trace 0000000000000000 ]--- 0000000000006108 <sdw_stream_add_slave>: 6108: d503233f paciasp 610c: a9b97bfd stp x29, x30, [sp, #-112]! 6110: 910003fd mov x29, sp 6114: a90153f3 stp x19, x20, [sp, #16] 6118: a9025bf5 stp x21, x22, [sp, #32] 611c: aa0103f6 mov x22, x1 6120: 2a0303f5 mov w21, w3 6124: a90363f7 stp x23, x24, [sp, #48] 6128: aa0003f8 mov x24, x0 612c: aa0203f7 mov x23, x2 6130: a9046bf9 stp x25, x26, [sp, #64] 6134: aa0403f9 mov x25, x4 <-- x4 copied to x25 6138: a90573fb stp x27, x28, [sp, #80] 613c: aa0403fb mov x27, x4 6140: f9418400 ldr x0, [x0, #776] 6144: 9100e000 add x0, x0, #0x38 6148: 94000000 bl 0 <mutex_lock> 614c: f8420f22 ldr x2, [x25, #32]! <-- offset 0x44 ^^^ This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave() where data abort happens. wsa881x_hw_params() is called with stream = NULL and passes it further in register x4 (5th argu ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: sdm845: agregar asignación de flujo de tiempo de ejecución de Soundwire faltante Durante la migración de la asignación de flujo de tiempo de ejecución de Soundwire desde el controlador Qualcomm Soundwire a los controladores de tarjeta de sonido del SoC, se olvidó la tarjeta de sonido sdm845. En este punto, cualquier intento de reproducción o inicio del demonio de audio, por ejemplo en sdm845-db845c (placa Qualcomm RB3), dará como resultado una desreferenciación del puntero de flujo NULL: No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000020 Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducción de nivel 0 Información de aborto de datos: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Superposición = 0, DirtyBit = 0, Xs = 0 usuario pgtable: páginas de 4k, VA de 48 bits, pgdp=0000000101ecf000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Error interno: Oops: 0000000096000004 [#1] PREEMPT Módulos SMP vinculados en: ... CPU: 5 UID: 0 PID: 1198 Comm: aplay No contaminado 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18 Nombre del hardware: Thundercomm Dragonboard 845c (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sdw_stream_add_slave+0x44/0x380 [bus_soundwire] lr : sdw_stream_add_slave+0x44/0x380 [bus_soundwire] sp : ffff80008a2035c0 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 000000000000000 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 00000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8 Rastreo de llamadas: sdw_stream_add_slave+0x44/0x380 [bus de cable de sonido] wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x] snd_soc_dai_hw_params+0x3c/0xa4 __soc_pcm_hw_params+0x230/0x660 dpcm_be_dai_hw_params+0x1d0/0x3f8 dpcm_fe_dai_hw_params+0x98/0x268 snd_pcm_hw_params+0x124/0x460 snd_pcm_common_ioctl+0x998/0x16e8 snd_pcm_ioctl+0x34/0x58 __arm64_sys_ioctl+0xac/0xf8 invocar_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xe0 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Código: aa0403fb f9418400 9100e000 9400102f (f8420f22) ---[ fin de seguimiento 000000000000000 ]--- 0000000000006108 : 6108: d503233f paciasp 610c: a9b97bfd stp x29, x30, [sp, #-112]! • https://git.kernel.org/stable/c/15c7fab0e0477d7d7185eac574ca43c15b59b015 https://git.kernel.org/stable/c/fc34d36879f87e5a3813fb66655b8bdb90c7b0d8 https://git.kernel.org/stable/c/d0e806b0cc6260b59c65e606034a63145169c04c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50103 – ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()
https://notcve.org/view.php?id=CVE-2024-50103
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: Se ha corregido la desreferencia NULL en asoc_qcom_lpass_cpu_platform_probe(). Una devm_kzalloc() en asoc_qcom_lpass_cpu_platform_probe() podría devolver un puntero NULL. La desreferencia de puntero NULL se puede activar sin una comprobación adicional. • https://git.kernel.org/stable/c/b5022a36d28f6a99c1a57f54246e8b566cf094d5 https://git.kernel.org/stable/c/03c9c2c2d2d0fe203dfe8f56bedbcf04e303d7c4 https://git.kernel.org/stable/c/a8e691fe1894c8bdf815a6171ee22ae7da8b18aa https://git.kernel.org/stable/c/e19bf49e903337641fc230d430d49813e3199902 https://git.kernel.org/stable/c/73cc3f905ca9aa95694eea3dfa1acadc90686368 https://git.kernel.org/stable/c/1e235d02d803660777ec911a2c467ae41f8539f5 https://git.kernel.org/stable/c/49da1463c9e3d2082276c3e0e2a8b65a88711cd2 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50102 – x86: fix user address masking non-canonical speculation issue
https://notcve.org/view.php?id=CVE-2024-50102
In the Linux kernel, the following vulnerability has been resolved: x86: fix user address masking non-canonical speculation issue It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result: CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“ Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window. But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open. Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers. It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86: se soluciona el problema de especulación no canónica de enmascaramiento de direcciones de usuario Resulta que AMD tiene un problema de "Meltdown Lite(tm)" con los accesos no canónicos en el espacio del kernel. Y entonces, usar solo el bit alto para decidir si un acceso está en el espacio del usuario o en el espacio del kernel termina con la buena y vieja "filtración de datos especulativos" si tienes el gadget correcto usando el resultado: CVE-2020-12965 "Ejecución transitoria de accesos no canónicos" Ahora, el kernel rodea el acceso con un par STAC/CLAC, y esas instrucciones terminan serializando la ejecución en arquitecturas Zen más antiguas, lo que cierra la ventana de especulación. Pero eso era cierto solo hasta Zen 5, que renombra el bit AC [1]. • https://git.kernel.org/stable/c/6014bc27561f2cc63e0acc18adbc4ed810834e32 https://git.kernel.org/stable/c/291313693677a345d4f50aae3c68e28b469f601e https://git.kernel.org/stable/c/86e6b1547b3d013bc392adf775b89318441403c2 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50101 – iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices
https://notcve.org/view.php?id=CVE-2024-50101
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige pci_for_each_dma_alias() incorrecto para dispositivos que no sean PCI Anteriormente, la función domain_context_clear() llamaba incorrectamente a pci_for_each_dma_alias() para configurar entradas de contexto para dispositivos que no sean PCI. Esto podría provocar bloqueos del kernel u otro comportamiento inesperado. Agregue una verificación para llamar solo a pci_for_each_dma_alias() para dispositivos PCI. • https://git.kernel.org/stable/c/9807860f6ad446459d0446550cf4a2dc23bbee6c https://git.kernel.org/stable/c/59862b869275c27beb25cda2054b59a8b5d04970 https://git.kernel.org/stable/c/48f2183a4f9d3540fc5cfc8f8451621ee92c09f8 https://git.kernel.org/stable/c/9a16ab9d640274b20813d2d17475e18d3e99d834 https://git.kernel.org/stable/c/0bd9a30c22afb5da203386b811ec31429d2caa78 https://git.kernel.org/stable/c/cbfa3a83eba05240ce37839ed48280a05e8e8f6c https://git.kernel.org/stable/c/fe2e0b6cd00abea3efac66de1da22d844364c1b0 https://git.kernel.org/stable/c/04d6826ba7ba81213422276e96c90c656 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50099 – arm64: probes: Remove broken LDR (literal) uprobe support
https://notcve.org/view.php?id=CVE-2024-50099
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. • https://git.kernel.org/stable/c/9842ceae9fa8deae141533d52a6ead7666962c09 https://git.kernel.org/stable/c/cc86f2e9876c8b5300238cec6bf0bd8c842078ee https://git.kernel.org/stable/c/ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9 https://git.kernel.org/stable/c/3728b4eb27910ffedd173018279a970705f2e03a https://git.kernel.org/stable/c/ad4bc35a6d22e9ff9b67d0d0c38bce654232f195 https://git.kernel.org/stable/c/bae792617a7e911477f67a3aff850ad4ddf51572 https://git.kernel.org/stable/c/9f1e7735474e7457a4d919a517900e46868ae5f6 https://git.kernel.org/stable/c/20cde998315a3d2df08e26079a3ea7501 •