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: 2EXPL: 0CVE-2022-48897 – arm64/mm: fix incorrect file_map_count for invalid pmd
https://notcve.org/view.php?id=CVE-2022-48897
In the Linux kernel, the following vulnerability has been resolved: arm64/mm: fix incorrect file_map_count for invalid pmd The page table check trigger BUG_ON() unexpectedly when split hugepage: ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:119! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748 Hardware name: linux,dummy-virt (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_set.isra.0+0x398/0x468 lr : page_table_check_set.isra.0+0x1c0/0x468 [...] Call trace: page_table_check_set.isra.0+0x398/0x468 __page_table_check_pte_set+0x160/0x1c0 __split_huge_pmd_locked+0x900/0x1648 __split_huge_pmd+0x28c/0x3b8 unmap_page_range+0x428/0x858 unmap_single_vma+0xf4/0x1c8 zap_page_range+0x2b0/0x410 madvise_vma_behavior+0xc44/0xe78 do_madvise+0x280/0x698 __arm64_sys_madvise+0x90/0xe8 invoke_syscall.constprop.0+0xdc/0x1d8 do_el0_svc+0xf4/0x3f8 el0_svc+0x58/0x120 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x19c/0x1a0 [...] On arm64, pmd_leaf() will return true even if the pmd is invalid due to pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count will not only decrease once but also increase once. Then in set_pte_at(), the file_map_count increase again, and so trigger BUG_ON() unexpectedly. Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the problem. • https://git.kernel.org/stable/c/42b2547137f5c974bb1bfd657c869fe96b96d86f https://git.kernel.org/stable/c/21e5eca0ac9046da9918a919bc92b7b5a78d27e7 https://git.kernel.org/stable/c/74c2f81054510d45b813548cb0a1c4ebf87cdd5f •
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 •