CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-4439 – isdn: cpai: check ctr->cnr to avoid array index out of bound
https://notcve.org/view.php?id=CVE-2021-4439
In the Linux kernel, the following vulnerability has been resolved: isdn: cpai: check ctr->cnr to avoid array index out of bound The cmtp_add_connection() would add a cmtp session to a controller and run a kernel thread to process cmtp. __module_get(THIS_MODULE); session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d", session->num); During this process, the kernel thread would call detach_capi_ctr() to detach a register controller. if the controller was not attached yet, detach_capi_ctr() would trigger an array-index-out-bounds bug. [ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted 5.15.0-rc2+ #8 [ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 46.870107][ T6479] Call Trace: [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40 [ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48 [ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0 [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0 [ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60 [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40 [ 46.875248][ T6479] ret_from_fork+0x1f/0x30 [ 46.875773][ T6479] • https://git.kernel.org/stable/c/e8b8de17e164c9f1b7777f1c6f99d05539000036 https://git.kernel.org/stable/c/24219a977bfe3d658687e45615c70998acdbac5a https://git.kernel.org/stable/c/9b6b2db77bc3121fe435f1d4b56e34de443bec75 https://git.kernel.org/stable/c/7d91adc0ccb060ce564103315189466eb822cc6a https://git.kernel.org/stable/c/285e9210b1fab96a11c0be3ed5cea9dd48b6ac54 https://git.kernel.org/stable/c/7f221ccbee4ec662e2292d490a43ce6c314c4594 https://git.kernel.org/stable/c/cc20226e218a2375d50dd9ac14fb4121b43375ff https://git.kernel.org/stable/c/1f3e2e97c003f80c4b087092b225c8787 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48769 – efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
https://notcve.org/view.php?id=CVE-2022-48769
In the Linux kernel, the following vulnerability has been resolved: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00. The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space. Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/ • https://git.kernel.org/stable/c/b0f1cc093bc2493ac259c53766fd2b800e085807 https://git.kernel.org/stable/c/3df52448978802ae15dcebf66beba1029df957b4 https://git.kernel.org/stable/c/a4085859411c825c321c9b55b8a9dc5a128a6684 https://git.kernel.org/stable/c/f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48766 – drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.
https://notcve.org/view.php?id=CVE-2022-48766
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: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48765 – KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
https://notcve.org/view.php?id=CVE-2022-48765
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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48763 – KVM: x86: Forcibly leave nested virt when SMM state is toggled
https://notcve.org/view.php?id=CVE-2022-48763
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 •