CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48707 – cxl/region: Fix null pointer dereference for resetting decoder
https://notcve.org/view.php?id=CVE-2022-48707
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix null pointer dereference for resetting decoder Not all decoders have a reset callback. The CXL specification allows a host bridge with a single root port to have no explicit HDM decoders. Currently the region driver assumes there are none. As such the CXL core creates a special pass through decoder instance without a commit/reset callback. Prior to this patch, the ->reset() callback was called unconditionally when calling cxl_region_decode_reset. Thus a configuration with 1 Host Bridge, 1 Root Port, and one directly attached CXL type 3 device or multiple CXL type 3 devices attached to downstream ports of a switch can cause a null pointer dereference. Before the fix, a kernel crash was observed when we destroy the region, and a pass through decoder is reset. The issue can be reproduced as below, 1) create a region with a CXL setup which includes a HB with a single root port under which a memdev is attached directly. 2) destroy the region with cxl destroy-region regionX -f. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: corrige la desreferencia del puntero null para restablecer el decodificador. • https://git.kernel.org/stable/c/176baefb2eb5d7a3ddebe3ff803db1fce44574b5 https://git.kernel.org/stable/c/a04c7d062b537ff787d00da95bdfe343260d4beb https://git.kernel.org/stable/c/4fa4302d6dc7de7e8e74dc7405611a2efb4bf54b •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48706 – vdpa: ifcvf: Do proper cleanup if IFCVF init fails
https://notcve.org/view.php?id=CVE-2022-48706
In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Do proper cleanup if IFCVF init fails ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vdpa: ifcvf: realice una limpieza adecuada si falla el inicio de IFCVF. ifcvf_mgmt_dev pierde memoria si no se libera antes de regresar. Se realiza una llamada para corregir la declaración de devolución para que no se pierda memoria. ifcvf_init_hw no se encarga de esto, por lo que es necesario hacerlo aquí. • https://git.kernel.org/stable/c/5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e https://git.kernel.org/stable/c/6b04456e248761cf68f562f2fd7c04e591fcac94 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47431 – drm/amdgpu: fix gart.bo pin_count leak
https://notcve.org/view.php?id=CVE-2021-47431
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix gart.bo pin_count leak gmc_v{9,10}_0_gart_disable() isn't called matched with correspoding gart_enbale function in SRIOV case. This will lead to gart.bo pin_count leak on driver unload. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: corrige la fuga de pin_count de gart.bo gmc_v{9,10}_0_gart_disable() no se llama y coincide con la función gart_enbale correspondiente en el caso SRIOV. Esto provocará una pérdida de pin_count de gart.bo al descargar el controlador. • https://git.kernel.org/stable/c/83d857d6b0967b6709cd38750c3ce2ed8ced1a95 https://git.kernel.org/stable/c/621ddffb70db824eabd63d18ac635180fe9500f9 https://git.kernel.org/stable/c/18d1c5ea3798ba42cfa0f8b2264d873463facb03 https://git.kernel.org/stable/c/66805763a97f8f7bdf742fc0851d85c02ed9411f •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47430 – x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n
https://notcve.org/view.php?id=CVE-2021-47430
In the Linux kernel, the following vulnerability has been resolved: x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n Commit 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks") added a warning if AC is set when in the kernel. Commit 662a0221893a3d ("x86/entry: Fix AC assertion") changed the warning to only fire if the CPU supports SMAP. However, the warning can still trigger on a machine that supports SMAP but where it's disabled in the kernel config and when running the syscall_nt selftest, for example: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode CPU: 0 PID: 49 Comm: init Tainted: G T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:irqentry_enter_from_user_mode ... Call Trace: ? irqentry_enter ? exc_general_protection ? asm_exc_general_protection ? asm_exc_general_protectio IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but even this would not be enough in case SMAP is disabled at boot time with the "nosmap" parameter. To be consistent with "nosmap" behaviour, clear X86_FEATURE_SMAP when ! • https://git.kernel.org/stable/c/3c73b81a9164d0c1b6379d6672d2772a9e95168e https://git.kernel.org/stable/c/231508fa9a6d038565c7bd6654200350ce2f7548 https://git.kernel.org/stable/c/f2447f6587b8ffe42ba04d14ce67d429a1163e5e https://git.kernel.org/stable/c/4e9ec1c65da98c293f75d83755dfa5e03075a6d0 https://git.kernel.org/stable/c/3958b9c34c2729597e182cc606cc43942fd19f7c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47429 – powerpc/64s: Fix unrecoverable MCE calling async handler from NMI
https://notcve.org/view.php?id=CVE-2021-47429
In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix unrecoverable MCE calling async handler from NMI The machine check handler is not considered NMI on 64s. The early handler is the true NMI handler, and then it schedules the machine_check_exception handler to run when interrupts are enabled. This works fine except the case of an unrecoverable MCE, where the true NMI is taken when MSR[RI] is clear, it can not recover, so it calls machine_check_exception directly so something might be done about it. Calling an async handler from NMI context can result in irq state and other things getting corrupted. This can also trigger the BUG at arch/powerpc/include/asm/interrupt.h:168 BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE)); Fix this by making an _async version of the handler which is called in the normal case, and a NMI version that is called for unrecoverable interrupts. • https://git.kernel.org/stable/c/2b43dd7653cca47d297756980846ebbfe8887fa1 https://git.kernel.org/stable/c/d7a8e38999fbd6910516e44cb43f9f4317e54f73 https://git.kernel.org/stable/c/f08fb25bc66986b0952724530a640d9970fa52c1 •