CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48899 – drm/virtio: Fix GEM handle creation UAF
https://notcve.org/view.php?id=CVE-2022-48899
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. • https://git.kernel.org/stable/c/62fb7a5e10962ac6ae2a2d2dbd3aedcb2a3e3257 https://git.kernel.org/stable/c/19ec87d06acfab2313ee82b2a689bf0c154e57ea https://git.kernel.org/stable/c/d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73 https://git.kernel.org/stable/c/68bcd063857075d2f9edfed6024387ac377923e2 https://git.kernel.org/stable/c/011ecdbcd520c90c344b872ca6b4821f7783b2f8 https://git.kernel.org/stable/c/adc48e5e408afbb01d261bd303fd9fbbbaa3e317 https://git.kernel.org/stable/c/52531258318ed59a2dc5a43df2eaf0eb1d65438e •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48896 – ixgbe: fix pci device refcount leak
https://notcve.org/view.php?id=CVE-2022-48896
In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix pci device refcount leak As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(), pci_dev_put() is called to avoid leak. • https://git.kernel.org/stable/c/8fa10ef01260937eb540b4e9bbc3efa023595993 https://git.kernel.org/stable/c/53cefa802f070d46c0c518f4865be2c749818a18 https://git.kernel.org/stable/c/112df4cd2b09acd64bcd18f5ef83ba5d07b34bf0 https://git.kernel.org/stable/c/4c93422a54cd6a349988f42e1c6bf082cf4ea9d8 https://git.kernel.org/stable/c/c49996c6aa03590e4ef5add8772cb6068d99fd59 https://git.kernel.org/stable/c/b93fb4405fcb5112c5739c5349afb52ec7f15c07 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48893 – drm/i915/gt: Cleanup partial engine discovery failures
https://notcve.org/view.php?id=CVE-2022-48893
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Cleanup partial engine discovery failures If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated. v2: - Drop the destroy_pinned_context() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz) • https://git.kernel.org/stable/c/5c855bcc730656c4b7d30aaddcd0eafc7003e112 https://git.kernel.org/stable/c/78a033433a5ae4fee85511ee075bc9a48312c79e •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48891 – regulator: da9211: Use irq handler when ready
https://notcve.org/view.php?id=CVE-2022-48891
In the Linux kernel, the following vulnerability has been resolved: regulator: da9211: Use irq handler when ready If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us. If we enable the IRQ handler before its structures are ready, we crash. This patch fixes: [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154 • https://git.kernel.org/stable/c/1c1afcb8839b91c09d211ea304faa269763b1f91 https://git.kernel.org/stable/c/f75cde714e0a67f73ef169aa50d4ed77d04f7236 https://git.kernel.org/stable/c/d443308edbfb6e9e757b478af908515110d1efd5 https://git.kernel.org/stable/c/d4aa749e046435f054e94ebf50cad143d6229fae https://git.kernel.org/stable/c/470f6a9175f13a53810734658c35cc5bba33be01 https://git.kernel.org/stable/c/ad1336274f733a7cb1f87b5c5908165a2c14df53 https://git.kernel.org/stable/c/02228f6aa6a64d588bc31e3267d05ff184d772eb •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48887 – drm/vmwgfx: Remove rcu locks from user resources
https://notcve.org/view.php?id=CVE-2022-48887
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Remove rcu locks from user resources User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources. • https://git.kernel.org/stable/c/e14c02e6b6990e9f6ee18a214a22ac26bae1b25e https://git.kernel.org/stable/c/7ac9578e45b20e3f3c0c8eb71f5417a499a7226a https://git.kernel.org/stable/c/a309c7194e8a2f8bd4539b9449917913f6c2cd50 •