CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-49006 – tracing: Free buffers when a used dynamic event is removed
https://notcve.org/view.php?id=CVE-2022-49006
In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. • https://git.kernel.org/stable/c/77b44d1b7c28360910cdbd427fb62d485c08674c https://git.kernel.org/stable/c/1603feac154ff38514e8354e3079a455eb4801e2 https://git.kernel.org/stable/c/be111ebd8868d4b7c041cb3c6102e1ae27d6dc1d https://git.kernel.org/stable/c/417d5ea6e735e5d88ffb6c436cf2938f3f476dd1 https://git.kernel.org/stable/c/c52d0c8c4f38f7580cff61c4dfe1034c580cedfd https://git.kernel.org/stable/c/4313e5a613049dfc1819a6dfb5f94cf2caff9452 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49002 – iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()
https://notcve.org/view.php?id=CVE-2022-49002
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak. • https://git.kernel.org/stable/c/2e45528930388658603ea24d49cf52867b928d3e https://git.kernel.org/stable/c/d47bc9d7bcdbb9adc9703513d964b514fee5b0bf https://git.kernel.org/stable/c/71c4a621985fc051ab86d3a86c749069a993fcb2 https://git.kernel.org/stable/c/876d7bfb89273997056220029ff12b1c2cc4691d https://git.kernel.org/stable/c/cbdd83bd2fd67142b03ce9dbdd1eab322ff7321f https://git.kernel.org/stable/c/a5c65cd56aed027f8a97fda8b691caaeb66d115e https://git.kernel.org/stable/c/bdb613ef179ad4bb9d56a2533e9b30e434f1dfb7 https://git.kernel.org/stable/c/2a8f7b90681472948de172dbbf5a54cd3 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48994 – ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event
https://notcve.org/view.php?id=CVE-2022-48994
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. • https://git.kernel.org/stable/c/b38486e82ecb9f3046e0184205f6b61408fc40c9 https://git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8158901d32a869e0adb6 https://git.kernel.org/stable/c/63badfed200219ca656968725f1a43df293ac936 https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa https://git.kernel.org/stable/c/fccd454129f6a0739651f7f58307cdb631fd6e89 https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48992 – ASoC: soc-pcm: Add NULL check in BE reparenting
https://notcve.org/view.php?id=CVE-2022-48992
In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-pcm: Add NULL check in BE reparenting Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test. • https://git.kernel.org/stable/c/0760acc2e6598ad4f7bd3662db2d907ef0838139 https://git.kernel.org/stable/c/d4dd21a79dbb862d2ebcf9ed90e646416009ff0d https://git.kernel.org/stable/c/e7166d6821c15f3516bcac8ae3f155924da1908c https://git.kernel.org/stable/c/f2ba66d8738584d124aff4e760ed1337f5f6dfb6 https://git.kernel.org/stable/c/f6f45e538328df9ce66aa61bafee1a5717c4b700 https://git.kernel.org/stable/c/9f74b9aa8d58c18927bb9b65dd5ba70a5fd61615 https://git.kernel.org/stable/c/34a9796bf0684bfd54e96a142560d560c21c983b https://git.kernel.org/stable/c/db8f91d424fe0ea6db337aca8bc05908b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48991 – mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
https://notcve.org/view.php?id=CVE-2022-48991
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables. khugepaged in Linux races with rmap-based zap, races with GUP-fast, and fails to call MMU notifiers. • https://git.kernel.org/stable/c/f3f0e1d2150b2b99da2cbdfaad000089efe9bf30 https://git.kernel.org/stable/c/275c626c131cfe141beeb6c575e31fa53d32da19 https://git.kernel.org/stable/c/c23105673228c349739e958fa33955ed8faddcaf https://git.kernel.org/stable/c/ff2a1a6f869650aec99e9d070b5ab625bfbc5bc3 https://git.kernel.org/stable/c/5ffc2a75534d9d74d49760f983f8eb675fa63d69 https://git.kernel.org/stable/c/7f445ca2e0e59c7971d0b7b853465e50844ab596 https://git.kernel.org/stable/c/1a3f8c6cd29d9078cc81b29d39d0e9ae1d6a03c3 https://git.kernel.org/stable/c/5450535901d89a5dcca5fbbc59a24fe89 •