CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52893 – gsmi: fix null-deref in gsmi_get_variable
https://notcve.org/view.php?id=CVE-2023-52893
In the Linux kernel, the following vulnerability has been resolved: gsmi: fix null-deref in gsmi_get_variable We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi. • https://git.kernel.org/stable/c/74c5b31c6618f01079212332b2e5f6c42f2d6307 https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5 https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2 https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393 https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd720 •
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: 4EXPL: 0CVE-2022-48898 – drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
https://notcve.org/view.php?id=CVE-2022-48898
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. • https://git.kernel.org/stable/c/c943b4948b5848fc0e07f875edbd35a973879e22 https://git.kernel.org/stable/c/785607e5e6fb52caf141e4580de40405565f04f1 https://git.kernel.org/stable/c/984ad875db804948c86ca9e1c2e784ae8252715a https://git.kernel.org/stable/c/b7dcbca46db3c77fdb02c2a9d6239e5aa3b06a59 https://git.kernel.org/stable/c/1cba0d150fa102439114a91b3e215909efc9f169 •
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 •