Page 17 of 3823 results (0.010 seconds)

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove cache tags before disabling ATS The current implementation removes cache tags after disabling ATS, leading to potential memory leaks and kernel crashes. Specifically, CACHE_TAG_DEVTLB type cache tags may still remain in the list even after the domain is freed, causing a use-after-free condition. This issue really shows up when multiple VFs from different PFs passed through to a single user-space process via vfio-pci. In such cases, the kernel may crash with kernel messages like: BUG: kernel NULL pointer dereference, address: 0000000000000014 PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2 RIP: 0010:cache_tag_flush_range+0x9b/0x250 Call Trace: <TASK> ? __die+0x1f/0x60 ? page_fault_oops+0x163/0x590 ? • https://git.kernel.org/stable/c/3b1d9e2b2d6856eabf5faa12d20c97fef657999f https://git.kernel.org/stable/c/9a0a72d3ed919ebe6491f527630998be053151d8 https://git.kernel.org/stable/c/1f2557e08a617a4b5e92a48a1a9a6f86621def18 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix qi_batch NULL pointer with nested parent domain The qi_batch is allocated when assigning cache tag for a domain. While for nested parent domain, it is missed. Hence, when trying to map pages to the nested parent, NULL dereference occurred. Also, there is potential memleak since there is no lock around domain->qi_batch allocation. To solve it, add a helper for qi_batch allocation, and call it in both the __cache_tag_assign_domain() and __cache_tag_assign_parent_domain(). BUG: kernel NULL pointer dereference, address: 0000000000000200 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8104795067 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 223 UID: 0 PID: 4357 Comm: qemu-system-x86 Not tainted 6.13.0-rc1-00028-g4b50c3c3b998-dirty #2632 Call Trace: ? __die+0x24/0x70 ? • https://git.kernel.org/stable/c/705c1cdf1e73c4c727bbfc8775434e6dd36e8baf https://git.kernel.org/stable/c/ffd774c34774fd4cc0e9cf2976595623a6c3a077 https://git.kernel.org/stable/c/74536f91962d5f6af0a42414773ce61e653c10ee •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix NULL pointer dereference in capture_engine When the intel_context structure contains NULL, it raises a NULL pointer dereference error in drm_info(). (cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d) • https://git.kernel.org/stable/c/e8a3319c31a14aa9925418bc7813c2866903b2c6 https://git.kernel.org/stable/c/e07f9c92bd127f8835ac669d83b5e7ff59bbb40f https://git.kernel.org/stable/c/e6ebe4f14a267bc431d0eebab4f335c0ebd45977 https://git.kernel.org/stable/c/da0b986256ae9a78b0215214ff44f271bfe237c1 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Dereference null return value In the function pqm_uninit there is a call-assignment of "pdd = kfd_get_process_device_data" which could be null, and this value was later dereferenced without checking. • https://git.kernel.org/stable/c/fb91065851cd5f2735348c5f3eddeeca3d7c2973 https://git.kernel.org/stable/c/768442d918932c4da09003f1fd6be1750b93a4ba https://git.kernel.org/stable/c/a592bb19abdc2072875c87da606461bfd7821b08 •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog Syzbot reported [1] crash that happens for following tracing scenario: - create tracepoint perf event with attr.inherit=1, attach it to the process and set bpf program to it - attached process forks -> chid creates inherited event the new child event shares the parent's bpf program and tp_event (hence prog_array) which is global for tracepoint - exit both process and its child -> release both events - first perf_event_detach_bpf_prog call will release tp_event->prog_array and second perf_event_detach_bpf_prog will crash, because tp_event->prog_array is NULL The fix makes sure the perf_event_detach_bpf_prog checks prog_array is valid before it tries to remove the bpf program from it. [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad • https://git.kernel.org/stable/c/7a5c653ede645693422e43cccaa3e8f905d21c74 https://git.kernel.org/stable/c/21db2f35fa97e4a3447f2edeb7b2569a8bfdc83b https://git.kernel.org/stable/c/0ee288e69d033850bc87abe0f9cc3ada24763d7f https://git.kernel.org/stable/c/b4007d5fe38625b8a1b8edc0f385d86527651238 https://git.kernel.org/stable/c/585674b9d0d80bd7f428b1f88be13cf6d5d6f739 https://git.kernel.org/stable/c/842e5af282453983586e2eae3c8eaf252de5f22f https://git.kernel.org/stable/c/c2b6b47662d5f2dfce92e5ffbdcac8229f321d9d https://git.kernel.org/stable/c/dfb15ddf3b65e0df2129f9756d1b4fa78 •