| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Use after free in iOSWeb in Google Chrome on on iOS prior to 156.0.8078.47 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: platform: Use acpi_bus_get_primary_device()
The acpi_get_first_physical_node() usage in acpi_platform_fill_resource()
and acpi_create_platform_device() is generally unsafe because in theory
the device returned by it may be freed at any time [1].
It is also inefficient because acpi_get_first_physical_node() is called
multiple times for the same argument which can be avoided.
Address these issues by using acpi_bus_get_primary_device() instead of
acpi_get_first_physical_node() and adjusting the code to call it just
once at the beginning of and acpi_create_platform_device() and drop
the device reference acquired by it upon the return from that function. |
| Untrusted pointer dereference in Windows Win32 Kernel Subsystem allows an authorized attacker to elevate privileges locally. |
| Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. From 2.1.0 until 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2, when an operator has enabled --enable-helm for kustomize build, helmGlobals.configHome can point Helm's config and data directories at a repository-controlled location. Helm automatically loads a downloader plugin from `<configHome>/.data/plugins` without a separate plugin-install step and executes its program inside argocd-repo-server when a helmCharts repository URL uses the plugin's protocol. The command runs as the repo-server user and can read repository credentials and other process-accessible data. An attacker can commit the Kustomization and plugin to a Git repository that an Application builds or upload the files through POST /api/v1/applications/manifestsWithFiles, also exposed by argocd app diff --local --server-side-generate. The upload path requires only Application get permission on an existing Application, without Application update or sync permission or repository write access. Both delivery paths require prior operator enablement of --enable-helm; deployments that do not enable it are not affected. Kustomize 4.1.0 first passed helmGlobals.configHome through to Helm. This issue is fixed in versions 3.3.15, 3.4.10, 3.5.4, and 3.6.0-rc2. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-30 and 6.9.13-55, when ImageMagick is built without Cairo support, a crafted RSVG image that reaches a resource limit can cause the RSVG decoder to free image state twice and then use freed memory, crashing the process. This issue is fixed in versions 7.1.2-30 and 6.9.13-55. |
| Memory safety bugs present in Thunderbird 152. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability was fixed in Firefox 153 and Thunderbird 153. |
| Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152 and Thunderbird 152. |
| Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12. |
| Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12. |
| Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12. |
| Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Thunderbird 152, and Thunderbird 140.12. |
| Memory safety bug fixed in Thunderbird 152. This vulnerability was fixed in Firefox 152, Firefox ESR 140.12, Firefox ESR 115.37, Thunderbird 152, and Thunderbird 140.12. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix mesh fast xmit path deletion UAF
mesh_fast_tx_cache() stores raw mesh_path pointers. Path deletion
flushes the cache and then frees the path with kfree_rcu(), but a
lookup that already holds the path can insert a new cache entry
after the flush. The cache then points at freed memory.
Set MESH_PATH_DELETED before flushing, and skip inserting a cache
entry if the path or MPP path is already deleted. Check this under
the cache walk lock so it is ordered with the flush. Use WRITE_ONCE()
for the deletion flag updates because the cache check reads flags
without taking state_lock. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: make nft_object rhltable per table
The nft_object rhltable is global, this allows for accessing objects
that are being dismangled from lookup path by other existing netns.
Given the nft_obj_destroy() releases the object inmediately, this might
lead to use-after-free of these objects that are being released.
Make the existing rhltable per table to address this issue to deal with
with the nft_rcv_nl_event() path too.
Update nft_obj_lookup() to take the table as non-const, otherwise,
compiler complains when passing the objname_ht to rhltable_lookup(). |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback
There is theoretical UAF if the conn is freed while the hci_sync task is
running.
Hold refcount to avoid that. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/iommufd: Fix IOPF group ownership UAF
iopf_group_alloc() links each last-page IOPF group into the generic IOPF
pending list before invoking the domain fault handler.
iommufd_fault_iopf_handler() also queued an accepted group in the
IOMMUFD deliver list without removing it from the generic pending list.
When detach or HWPT replacement drops the device's IOPF reference count
to zero, an IOMMU driver may call iopf_queue_remove_device(). That
function responds to and frees groups through the generic pending list
without removing the same groups from IOMMUFD's deliver list or response
xarray. A later read, response, or cleanup can then access the freed
group and cause a UAF.
Fix this by dequeuing an accepted group from the generic pending list
before IOMMUFD queues it for userspace response.
Make iopf_group_response() send a response regardless of pending-list
membership, so the dequeued group can still be completed by IOMMUFD. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Free SRQ toggle page after firmware teardown
Free the toggle page only after firmware teardown completes so that
an NQ interrupt arriving during bnxt_qplib_destroy_srq() won't write
the toggle values to an already-freed page. Move free_page() after
bnxt_qplib_destroy_srq(). |
| In the Linux kernel, the following vulnerability has been resolved:
net/handshake: Drain pending requests at net namespace exit
The arguments to list_splice_init() in handshake_net_exit() are
reversed. The call moves the local empty "requests" list onto
hn->hn_requests, leaving the local list empty, so the subsequent
drain loop runs zero iterations. Pending handshake requests that
had not yet been accepted are not torn down when the net namespace
is destroyed; each one keeps a reference on a socket file and on
the handshake_req allocation.
Pass the source and destination in the documented order
(list_splice_init(list, head) moves list onto head) so the pending
list is transferred to the local scratch list and drained through
handshake_complete().
Fixing the splice direction exposes a list-corruption race. After
the splice each req->hr_list still has non-empty link pointers,
threading the stack-local scratch list rather than hn_requests.
A concurrent handshake_req_cancel() -- for example, from sunrpc's
TLS timeout on a kernel socket whose netns reference was not
taken -- finds the request through the rhashtable, calls
remove_pending(), and sees !list_empty(&req->hr_list).
__remove_pending_locked() then list_del_init()s an entry off the
scratch list while the drain iterates, corrupting it. The same
call arriving after the drain loop has run list_del() on an
entry hits LIST_POISON instead.
Have remove_pending() check HANDSHAKE_F_NET_DRAINING under
hn_lock and report not-found when drain is in progress. The
drain has already taken ownership; handshake_complete()'s existing
test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates
between drain and cancel for who calls the consumer's hp_done. Use
list_del_init() rather than list_del() in the drain so req->hr_list
does not carry LIST_POISON after drain releases the entry.
The DRAINING guard in remove_pending() makes cancel return false,
but cancel still falls through to test_and_set_bit on
HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference.
Without another pin, if that is the last reference, sk_destruct frees
the request while it is still linked on the drain loop's local list.
Pin each request's hr_file under hn_lock before releasing the list,
and drop that drain pin after the loop finishes with the request. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold()
damon_hugetlb_mkold() reads the page table entry into a local variable,
unsets the accessed bit in the variable, and updates the page table entry
with the updated variable value. If hardware updates the same page table
entry in parallel, the hw updates could be lost. For example,
hardware-updated dirty bits might be lost.
Avoid the parallel updates by clearing the page table entry when reading
it together, using huge_ptep_get_and_clear(). If a parallel write to the
memory is made after the clearing, the hw will see the page table entry is
cleared, trigger page fault and wait until it is handled. The page fault
handling will wait for damon_hugetlb_mkold() due to the page table lock.
Because hugetlbfs is an in-memory file system and hugetlb pages cannot be
reclaimed, no critical issue is expected to my best knowledge. But
definitely this is a nasty bug that should be fixed sooner rather than
later.
The issue was discovered [1] by Sashiko. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Check ancestor frames for rbtree callbacks
bpf_rbtree_add() invokes its comparator while the caller holds the root
lock. The native insertion code retains raw parent and link pointers across
the callback, so the verifier prohibits unlocking, consuming tree nodes,
or changing RCU state from that callback.
in_rbtree_lock_required_cb() only checks the innermost verifier frame.
Static subprogram calls are permitted while holding a spin lock, and such a
call pushes a frame without in_callback_fn set. Consequently, all callback
restrictions disappear in the nested frame. The subprogram can unlock the
tree, remove and drop the node being compared, then relock. Native insertion
resumes with the stale parent pointer and links freed memory into the tree.
Walk all active frames for the rbtree callback instead. Benign static
subprograms remain permitted, while callback restrictions follow execution
into nested frames. |
