CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50108 – drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too
https://notcve.org/view.php?id=CVE-2024-50108
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: 0CVE-2024-50106 – nfsd: fix race between laundromat and free_stateid
https://notcve.org/view.php?id=CVE-2024-50106
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: 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 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50095 – RDMA/mad: Improve handling of timed out WRs of mad agent
https://notcve.org/view.php?id=CVE-2024-50095
In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl+0x1c4/0x2df ? • https://git.kernel.org/stable/c/713adaf0ecfc49405f6e5d9e409d984f628de818 https://git.kernel.org/stable/c/7022a517bf1ca37ef5a474365bcc5eafd345a13a https://git.kernel.org/stable/c/e80eadb3604a92d2d086e956b8b2692b699d4d0a https://git.kernel.org/stable/c/a195a42dd25ca4f12489687065d00be64939409f https://git.kernel.org/stable/c/3e799fa463508abe7a738ce5d0f62a8dfd05262a https://git.kernel.org/stable/c/2a777679b8ccd09a9a65ea0716ef10365179caac •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50091 – dm vdo: don't refer to dedupe_context after releasing it
https://notcve.org/view.php?id=CVE-2024-50091
In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm vdo: no hacer referencia a dedupe_context después de liberarlo. Borre el puntero dedupe_context en un data_vio siempre que se pierda la propiedad del contexto, de modo que vdo no pueda examinarlo accidentalmente. • https://git.kernel.org/stable/c/63ef073084c67878d7a92e15ad055172da3f05a3 https://git.kernel.org/stable/c/0808ebf2f80b962e75741a41ced372a7116f1e26 •