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: 3EXPL: 0CVE-2022-48892 – sched/core: Fix use-after-free bug in dup_user_cpus_ptr()
https://notcve.org/view.php?id=CVE-2022-48892
In the Linux kernel, the following vulnerability has been resolved: sched/core: Fix use-after-free bug in dup_user_cpus_ptr() Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel. Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). • https://git.kernel.org/stable/c/07ec77a1d4e82526e1588979fff2f024f8e96df2 https://git.kernel.org/stable/c/b22faa21b6230d5eccd233e1b7e0026a5002b287 https://git.kernel.org/stable/c/7b5cc7fd1789ea5dbb942c9f8207b076d365badc https://git.kernel.org/stable/c/87ca4f9efbd7cc649ff43b87970888f2812945b8 •
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 •