Page 14 of 3824 results (0.009 seconds)

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too Stuart Hayhurst has found that both at bootup and fullscreen VA-API video is leading to black screens for around 1 second and kernel WARNING [1] traces when calling dmub_psr_enable() with Parade 08-01 TCON. These symptoms all go away with PSR-SU disabled for this TCON, so disable it for now while DMUB traces [2] from the failure can be analyzed and the failure state properly root caused. (cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Deshabilitar PSR-SU también en Parade 08-01 TCON Stuart Hayhurst ha descubierto que tanto en el arranque como en pantalla completa, el vídeo VA-API provoca pantallas negras durante alrededor de 1 segundo y rastros de ADVERTENCIA [1] en el kernel al llamar a dmub_psr_enable() con Parade 08-01 TCON. Todos estos síntomas desaparecen con PSR-SU deshabilitado para este TCON, así que deshabilítelo por ahora mientras se pueden analizar los rastros DMUB [2] del fallo y se puede determinar correctamente el estado del fallo. (seleccionado de la confirmación afb634a6823d8d9db23c5fb04f79c5549349628b) • https://git.kernel.org/stable/c/5660bcc4dd533005248577d5042f1c48cce2b443 https://git.kernel.org/stable/c/c79e0a18e4b301401bb745702830be9041cfbf04 https://git.kernel.org/stable/c/fc6afa07b5e251148fb37600ee06e1a7007178c3 https://git.kernel.org/stable/c/ba1959f71117b27f3099ee789e0815360b4081dd •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix race between laundromat and free_stateid There is a race between laundromat handling of revoked delegations and a client sending free_stateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing free_stateid processing thread does the following (1) it calls list_del_init() which removes it from the reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the revoke_delegation() function for this particular delegation but that means it will no release the lock lease that exists on the file. Now, a new open for this file comes in and ends up finding that lease list isn't empty and calls nfsd_breaker_owns_lease() which ends up trying to derefence a freed delegation stateid. Leading to the followint use-after-free KASAN warning: kernel: ================================================================== kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9 kernel: Hardware name: Apple Inc. • https://git.kernel.org/stable/c/2d4a532d385f635ab8243b88db3136bb52a0bc29 https://git.kernel.org/stable/c/967faa26f313a62e7bebc55d5b8122eaee43b929 https://git.kernel.org/stable/c/8dd91e8d31febf4d9cca3ae1bb4771d33ae7ee5a •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

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: 8EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nouveau/dmem: Se corrige la vulnerabilidad en migrants_to_ram tras un error de copia. La función `nouveau_dmem_copy_one` garantiza que el comando de copia push se envíe al firmware del dispositivo, pero no rastrea si se ejecutó correctamente. En el caso de un error de copia (por ejemplo, fallo del firmware o hardware), el comando de copia push se enviará a través del canal de firmware y `nouveau_dmem_copy_one` probablemente informará el éxito, lo que llevará a la función `migrate_to_ram` a devolver una página HIGH_USER sucia al usuario. • https://git.kernel.org/stable/c/5be73b690875f7eb2d2defb54ccd7f2f12074984 https://git.kernel.org/stable/c/fd9bb7e996bab9b9049fffe3f3d3b50dee191d27 https://git.kernel.org/stable/c/73f75d2b5aee5a735cf64b8ab4543d5c20dbbdd9 https://git.kernel.org/stable/c/8c3de9282dde21ce3c1bf1bde3166a4510547aa9 https://git.kernel.org/stable/c/614bfb2050982d23d53d0d51c4079dba0437c883 https://git.kernel.org/stable/c/697e3ddcf1f8b68bd531fc34eead27c000bdf3e1 https://git.kernel.org/stable/c/ab4d113b6718b076046018292f821d5aa4b844f8 https://git.kernel.org/stable/c/835745a377a4519decd1a36d6b926e369 •