Page 243 of 2860 results (0.006 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: tracing/histogram: Fix a potential memory leak for kstrdup() kfree() is missing on an error path to free the memory allocated by kstrdup(): p = param = kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). • https://git.kernel.org/stable/c/38b67e60b6b582e81f9db1b2e7176cbbfbd3e574 https://git.kernel.org/stable/c/d380dcde9a07ca5de4805dee11f58a98ec0ad6ff https://git.kernel.org/stable/c/c78a2baf5e1fe1b38121d6b54bab77ccb81a1a86 https://git.kernel.org/stable/c/8a8878ebb596281f50fc0b9a6e1f23f0d7f154e8 https://git.kernel.org/stable/c/d71b06aa995007eafd247626d0669b9364c42ad7 https://git.kernel.org/stable/c/e33fa4a46ee22de88a700e2e3d033da8214a5175 https://git.kernel.org/stable/c/df86e2fe808c3536a9dba353cc2bebdfea00d0cf https://git.kernel.org/stable/c/e629e7b525a179e29d53463d992bdee75 •

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

In the Linux kernel, the following vulnerability has been resolved: ceph: properly put ceph_string reference after async create attempt The reference acquired by try_prep_async_create is currently leaked. Ensure we put it. • https://git.kernel.org/stable/c/9a8d03ca2e2c334d08ee91a3e07dcce31a02fdc6 https://git.kernel.org/stable/c/e7be12ca7d3947765b0d7c1c7e0537e748da993a https://git.kernel.org/stable/c/36d433ae3242aa714176378850e6d1a5a3e78f18 https://git.kernel.org/stable/c/a0c22e970cd78b81c94691e6cb09713e8074d580 https://git.kernel.org/stable/c/932a9b5870d38b87ba0a9923c804b1af7d3605b9 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU. Mirrors the logic for dcn30. Cue lots of WARNs and some kernel panics without this fix. • https://git.kernel.org/stable/c/456ba2433844a6483cc4c933aa8f43d24575e341 https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f •

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

In the Linux kernel, the following vulnerability has been resolved: KVM: LAPIC: Also cancel preemption timer during SET_LAPIC The below warning is splatting during guest reboot. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm] Call Trace: <TASK> kvm_vcpu_ioctl+0x279/0x710 [kvm] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapic_shutdown() function which is called in sys_reboot path will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apic_update_lvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVM_SET_LAPIC. • https://git.kernel.org/stable/c/54b3439c8e70e0bcfea59aeef9dd98908cbbf655 https://git.kernel.org/stable/c/ce55f63f6cea4cab8ae9212f73285648a5baa30d https://git.kernel.org/stable/c/35fe7cfbab2e81f1afb23fc4212210b1de6d9633 https://access.redhat.com/security/cve/CVE-2022-48765 https://bugzilla.redhat.com/show_bug.cgi?id=2293344 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Forcibly leave nested virt when SMM state is toggled Forcibly leave nested virtualization operation if userspace toggles SMM state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace forces the vCPU out of SMM while it's post-VMXON and then injects an SMI, vmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both vmxon=false and smm.vmxon=false, but all other nVMX state allocated. Don't attempt to gracefully handle the transition as (a) most transitions are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't sufficient information to handle all transitions, e.g. SVM wants access to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede KVM_SET_NESTED_STATE during state restore as the latter disallows putting the vCPU into L2 if SMM is active, and disallows tagging the vCPU as being post-VMXON in SMM if SMM is not active. Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX due to failure to free vmcs01's shadow VMCS, but the bug goes far beyond just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU in an architecturally impossible state. WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline] WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Modules linked in: CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline] RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656 Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00 Call Trace: <TASK> kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123 kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline] kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460 kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline] kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676 kvm_destroy_vm arch/x86/kvm/../../.. • https://git.kernel.org/stable/c/080dbe7e9b86a0392d8dffc00d9971792afc121f https://git.kernel.org/stable/c/e302786233e6bc512986d007c96458ccf5ca21c7 https://git.kernel.org/stable/c/b4c0d89c92e957ecccce12e66b63875d0cc7af7e https://git.kernel.org/stable/c/f7e570780efc5cec9b2ed1e0472a7da14e864fdb •