CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48772 – media: lgdt3306a: Add a check against null-pointer-def
https://notcve.org/view.php?id=CVE-2022-48772
In the Linux kernel, the following vulnerability has been resolved: media: lgdt3306a: Add a check against null-pointer-def The driver should check whether the client provides the platform_data. The following log reveals it: [ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? • https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0 https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4 https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676 https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87 https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115 https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d •
CVSS: 8.8EPSS: 0%CPEs: 1EXPL: 0CVE-2021-4440 – x86/xen: Drop USERGS_SYSRET64 paravirt call
https://notcve.org/view.php?id=CVE-2021-4440
In the Linux kernel, the following vulnerability has been resolved: x86/xen: Drop USERGS_SYSRET64 paravirt call commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream. USERGS_SYSRET64 is used to return from a syscall via SYSRET, but a Xen PV guest will nevertheless use the IRET hypercall, as there is no sysret PV hypercall defined. So instead of testing all the prerequisites for doing a sysret and then mangling the stack for Xen PV again for doing an iret just use the iret exit from the beginning. This can easily be done via an ALTERNATIVE like it is done for the sysenter compat case already. It should be noted that this drops the optimization in Xen for not restoring a few registers when returning to user mode, but it seems as if the saved instructions in the kernel more than compensate for this drop (a kernel build in a Xen PV guest was slightly faster with this patch applied). While at it remove the stale sysret32 remnants. [ pawan: Brad Spengler and Salvatore Bonaccorso <carnil@debian.org> reported a problem with the 5.10 backport commit edc702b4a820 ("x86/entry_64: Add VERW just before userspace transition"). When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in syscall_return_via_sysret path as USERGS_SYSRET64 is runtime patched to: .cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8, 0x48, 0x0f, 0x07 }, // swapgs; sysretq which is missing CLEAR_CPU_BUFFERS. ... Below is with CONFIG_PARAVIRT_XXL=y and this patch applied: syscall_return_via_sysret: ... <+342>: swapgs <+345>: xchg %ax,%ax <+347>: verw -0x1a2(%rip) <------ <+354>: sysretq ] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/xen: elimine el commit de llamada paravirt USERGS_SYSRET64 afd30525a659ac0ae0904f0cb4a2ca75522c3123 en sentido ascendente. • https://git.kernel.org/stable/c/cea750c99d8f6391080c420f811a46b21bad7cf4 https://git.kernel.org/stable/c/1424ab4bb386df9cc590c73afa55f13e9b00dea2 https://grsecurity.net/cve-2021-4440_linux_cna_case_study • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-37026 – drm/xe: Only use reserved BCS instances for usm migrate exec queue
https://notcve.org/view.php?id=CVE-2024-37026
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Only use reserved BCS instances for usm migrate exec queue The GuC context scheduling queue is 2 entires deep, thus it is possible for a migration job to be stuck behind a fault if migration exec queue shares engines with user jobs. • https://git.kernel.org/stable/c/a043fbab7af54c64017269dc96f43f441ed4bcaf https://git.kernel.org/stable/c/92deed4a9bfd9ef187764225bba530116c49e15c https://git.kernel.org/stable/c/c8ea2c31f5ea437199b239d76ad5db27343edb0c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-37021 – fpga: manager: add owner module and take its refcount
https://notcve.org/view.php?id=CVE-2024-37021
In the Linux kernel, the following vulnerability has been resolved: fpga: manager: add owner module and take its refcount The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. • https://git.kernel.org/stable/c/654ba4cc0f3ed7c0f08bfb39f66059d8c42943ee https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36479 – fpga: bridge: add owner module and take its refcount
https://notcve.org/view.php?id=CVE-2024-36479
In the Linux kernel, the following vulnerability has been resolved: fpga: bridge: add owner module and take its refcount The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. • https://git.kernel.org/stable/c/21aeda950c5f84a8351b862816d832120b217a9b https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125 https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529 •