Page 36 of 3051 results (0.010 seconds)

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

05 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: Th... • https://git.kernel.org/stable/c/e4e517b4be019787ada4cbbce2f04570c21b0cbd • CWE-125: Out-of-bounds Read •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

05 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: x86/lam: Disable ADDRESS_MASKING in most cases Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in ... • https://git.kernel.org/stable/c/60a5ba560f296ad8da153f6ad3f70030bfa3958f •

CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0

05 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_aft... • https://git.kernel.org/stable/c/c7a5899eb26e2a4d516d53f65b6dd67be2228041 • CWE-908: Use of Uninitialized Resource •

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

05 Nov 2024 — 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 caus... • https://git.kernel.org/stable/c/5660bcc4dd533005248577d5042f1c48cce2b443 •

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

05 Nov 2024 — 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_... • https://git.kernel.org/stable/c/b5022a36d28f6a99c1a57f54246e8b566cf094d5 •

CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0

05 Nov 2024 — 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 ext... • https://git.kernel.org/stable/c/9842ceae9fa8deae141533d52a6ead7666962c09 •

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

05 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To ... • https://git.kernel.org/stable/c/b294ff3e34490f36233230e9ca70503d3924a6f3 •

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

05 Nov 2024 — 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` fun... • https://git.kernel.org/stable/c/5be73b690875f7eb2d2defb54ccd7f2f12074984 •

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

05 Nov 2024 — 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! [k... • https://git.kernel.org/stable/c/713adaf0ecfc49405f6e5d9e409d984f628de818 •

CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0

05 Nov 2024 — In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is exposed and triggers th... • https://git.kernel.org/stable/c/acd65d5d1cf4a3324c8970ba74632abe069fe23e •