Search: ge.call

Multiple Use-After-Free vulnerabilities were found in the add_archive_element function in ld/ldmain.c of the GNU linker (ld), a component of binutils. The root cause is that plugin_maybe_claim() in ld/plugin.c frees the original BFD object via bfd_close/_bfd_delete_bfd when entry->the_bfd->my_archive == NULL, but the caller retains both the original abfd parameter and a shallow copy (orig_input.the_bfd) as dangling pointers. These dangling pointers are subsequently dereferenced at three distinct locations in add_archive_element: 1. Line ~1442: accessing abfd->my_archive via bfd_usrdata(abfd->my_archive) 2. Line ~1493: multiple accesses to abfd and abfd->my_archive in a conditional check and bfd_get_filename call 3. Line ~1525: dereferencing the shallow copy orig_input.the_bfd->my_archive in trace/verbose logging The vulnerability is triggered when LTO plugins are active (link_info.lto_plugin_active is true) and the input object has abfd->my_archive == NULL, which is a valid state for standalone object files. Red Hat builds binutils with --enable-plugins and --enable-lto, confirming the vulnerable code path is compiled in and reachable. An attacker who can supply a crafted object or archive file to a build process using LTO-enabled linking could exploit this flaw to cause a denial of service (linker crash via segmentation fault). Arbitrary code execution is theoretically possible through heap manipulation but is substantially mitigated by hardening measures including stack protector, FORTIFY_SOURCE, ASLR, and PIE. The attack surface is limited to build-time environments — the linker is a development tool not exposed in production runtime. The most realistic exploitation scenario is a supply chain attack introducing a crafted object file as a build dependency in CI/CD pipelines or development environments.

A new NFC relay malware family called WindRelay has been discovered operating in combination with SpyNote RAT to enable sophisticated contactless payment fraud. The scheme uses live social engineering phone calls where fraudsters impersonate bank employees and guide victims to install personalized RAT malware labeled with the victim's own name. Once installed, the RAT enables silent deployment of WindRelay, which captures contactless payment card data via NFC when victims tap their cards to their phones. The captured data is relayed in real-time to fraudster-controlled terminals for immediate cash-out through physical purchases or ATM withdrawals. The operation employs dual monetization, combining RAT-driven digital loan fraud with NFC-based card-present transactions. Group-IB identified 23 WindRelay samples targeting victims in Czechia, Slovakia, and Slovenia between November 2025 and July 2026.

Malware#windrelay#android banking trojanCzechia+3

The Google Cloud Secret Manager secrets backend in Apache Airflow's Google provider never applied the team scope when resolving Connections and Variables: the caller's `team_name` was accepted by the backend but dropped at the internal call boundary, so every lookup resolved against the team-agnostic secret name. In a deployment running multi-team mode with this backend, a task or Dag belonging to one team resolved another team's Connection or Variable, obtaining its credentials in full. No unusual configuration is required beyond enabling multi-team mode and using this backend. Users are advised to upgrade to apache-airflow-providers-google 22.3.0 or later, which builds and applies the team-scoped secret name.

The Intel ALH digital-audio-interface driver function dai_alh_get_properties() in drivers/dai/intel/alh/alh.c used a caller-supplied int stream_id with no range validation. The value indexes the fixed-size static const uint8_t alh_handshake_map[64] array and scales a FIFO register address, so an out-of-range stream_id produces an out-of-bounds read of one byte at an attacker-chosen signed offset from the array. That byte is written into prop->dma_hs_id and the resulting struct dai_properties is copied back to the caller, leaking it. dai_get_properties_copy() is a Zephyr __syscall, and its verifier z_vrfy_dai_get_properties_copy() (drivers/dai/dai_handlers.c) validates only the device-object permission and the destination buffer, not stream_id. A user-mode thread that has been granted access to the ALH DAI device object can therefore call the syscall with an arbitrary stream_id, crossing the userspace/kernel sandbox boundary. The impact is a one-byte-per-call arbitrary-offset kernel information disclosure (and leakage of a computed kernel address via fifo_address); a stream_id that resolves to an unmapped page faults in kernel context, giving a local denial of service. Exploitation requires CONFIG_USERSPACE and device access, making this a local, moderate-severity issue. The fix rejects negative and too-large stream_id values up front and returns NULL, which the copy wrapper maps to -ENOENT.

A vulnerability in the Linux kernel's drm/amdgpu/gfx8 component involved an unnecessary BUG_ON() call that could cause the kernel to crash. This issue has been resolved by removing the unnecessary kernel crash trigger. The flaw could lead to a denial of service by crashing the system. Multiple Linux kernel versions are affected, and fixed versions have been released.

calibre is an e-book manager. Prior to 9.12.0, calibre processes attacker-controlled composite_template metadata from a malicious EPUB, OPF, PDF, or similar file through program: and a nested template() call whose formatter does not inherit allow_python_templates=False, allowing a nested python: template to reach compile_python_template and execute arbitrary Python code when the file is opened or imported. This issue is fixed in version 9.12.0.

OpenIM Server v3.8.3 contains a missing authorization vulnerability that allows any authenticated user to access admin-only management API endpoints by submitting POST requests with a regular user bearer token to /user/get_users, /user/get_all_users_uid, and /group/get_groups. Attackers can exploit the absent authverify.CheckAdmin() call in the GetPaginationUsers, GetAllUserID, and GetGroups handlers to enumerate all platform user accounts including userIDs, nicknames, and manager level flags, as well as all groups including private groups the user has never joined, exposing group names, owner IDs, and member counts.

Craft CMS versions 4.0.0-RC1 through before 4.18.3 and 5.0.0-RC1 through before 5.10.7 contain a remote code execution vulnerability via the Twig sandbox escape. An authenticated user with control panel access can exploit the vulnerability by rendering a malicious Twig template that abuses the yii\base\Component arbitrary function-call gadget, enabling arbitrary code execution even when the Twig sandbox is enabled.

Craft CMS versions >= 5.0.0-RC1 before 5.10.7 and >= 4.0.0-RC1 before 4.18.3 contain a remote code execution vulnerability in the Twig sandbox mechanism. Because Craft marks the ElementInterface as safe (via the AllowedInSandbox attribute) and the sandbox allowlisting extends to the entire class hierarchy (craft\base\Component up to yii\base\Component), an authenticated attacker with permission to access the control panel can render a malicious Twig template that abuses the yii\base\Component arbitrary function-call gadget to execute arbitrary code, even when the Twig sandbox is enabled via enableTwigSandbox().

Affected versions of cti-transmute fail to HTML-escape attacker-controlled values used in ECharts Sunburst and Treemap tooltip formatters. Slice names may originate directly from STIX or MISP data, including STIX types, relationship_type, pattern prefixes, and MISP category/type values. Since ECharts interprets the formatter return value as HTML, crafted values can inject markup or script-capable content into the tooltip. An attacker who can cause malicious conversion data to be processed can therefore inject content that executes when another user views the visualization and hovers over the affected slice. The patch replaces direct interpolation with dedicated formatter functions that call escapeHtml() on p.name, p.data.value, and p.value.

The Realtek BEE Bluetooth HCI driver's send callback, bt_hci_bee_send() in drivers/bluetooth/hci/hci_bee.c, violated the bt_hci_driver_api buffer-ownership contract. That contract requires the driver to consume (unref) the transmit net_buf only on success; on an error return the host caller retains ownership and unrefs the buffer itself. The pre-fix code routed all error paths through a shared cleanup label that unconditionally called net_buf_unref(buf) before returning the error code. Because the host TX paths (in subsys/bluetooth/host/hci_core.c) unref the buffer again after send() returns an error, the buffer is freed twice: the driver returns it to its net_buf pool and the host then unrefs the already-freed buffer, corrupting the shared pool / underflowing the reference count (CWE-415). The same error branch additionally dereferenced buf->len inside a LOG_ERR call after the buffer had already been unref'd, a read of freed memory (CWE-416) that is compiled in at the default error log level. The failing edges are reached when the controller's host-to-controller buffer allocation fails or the controller send fails (resource-exhaustion / IO conditions). A remote Bluetooth peer can push the device toward these conditions indirectly by driving heavy host transmit activity, at which point the double-free corrupts the host net_buf pool and most likely crashes the device, with residual potential for further memory corruption. The impact is confined to builds using this specific Realtek BEE HCI driver. The fix returns early from each error path without unreffing and unrefs the buffer only on the success path, restoring the ownership contract and eliminating both the double-free and the use-after-free read.

AnythingLLM is an application that turns pieces of content into context that any LLM can use as references during chatting. From 1.0.0 to 1.15.0, AnythingLLM's unauthenticated account-recovery flow in server/utils/PasswordRecovery/index.js uses recoverAccount() to deduplicate the raw recoveryCodes values before trimming them, so one valid code submitted twice with different surrounding whitespace can satisfy the two-code check. Each normalized value can also match the same stored hash instead of consuming a distinct hash. An attacker who knows the target username and one recovery code can call POST /api/system/recover-account in multi-user mode, receive a password-reset token, and use POST /api/system/reset-password to take over the account, including an administrator account.

The UpdateHub OTA client in subsys/mgmt/updatehub/updatehub.c contains an out-of-bounds / uninitialized-memory read in z_impl_updatehub_probe(). The probe response from the UpdateHub server is copied into a heap buffer (metadata) that is correctly NUL-terminated, but a second buffer (metadata_copy) is allocated with k_malloc (unzeroed) and filled with memcpy(metadata_copy, metadata, strlen(metadata)), which omits the terminating NUL. Everything after the copied content remains uninitialized heap. When the first json_obj_parse() over the array descriptor fails, the code falls back to json_obj_parse(metadata_copy, strlen(metadata_copy), ...). The strlen() call scans past the copied bytes through uninitialized heap and, if no zero byte is found before the end of the allocation, reads beyond the buffer; the resulting over-long length is then parsed as JSON. The probe payload is fully controlled by the (malicious, compromised, or — without the optional CONFIG_UPDATEHUB_DTLS — on-path) UpdateHub server, which can craft a large payload that fails the first parse to drive this path. The consequence is a read of uninitialized heap, with a worst case of an out-of-bounds read past the metadata_copy allocation that can fault and crash the update thread/device, producing a network-triggerable denial of service. The over-read data is consumed only internally to evaluate the update and is not returned to the attacker, so there is no direct information disclosure and no out-of-bounds write. The fix zeroes metadata_copy with memset before the copy, guaranteeing NUL termination and bounding strlen() within the allocation.

goose is general-purpose AI agent that runs on your machine. Prior to 1.44.0, the `goose review` command runs the system `git` executable to gather the diff for review without stripping attacker-controlled Git configuration. A malicious repository whose `.git/config` sets [`core] fsmonitor = <command>` causes Git to execute that command on the host during the index refresh performed by `git diff HEAD`. The command runs before goose contacts a model and without a submitted prompt, model call, tool approval, or trust prompt. The context-gathering Git process is not sandboxed and is outside goose's tool-permission model. Arbitrary commands run with the privileges and environment of the user running goose, allowing file access or modification and exfiltration of environment secrets and provider API keys. The vulnerable Git invocations are built by git_command() in crates/goose-cli/src/commands/review/handler.rs and are used by touched_files() and collect_diff() for `git diff --name-only HEAD` and `git diff HEAD`. This issue is fixed in version 1.44.0.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: synchronize delayed set_alt with teardown The f_tcm set_alt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses f_tcm private state and may complete the setup request after disconnect or function teardown has already moved on. Cancel and drain the delayed set_alt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancel_work_sync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcm_disable() can cancel the queued work and clean up immediately. Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayed_status while the worker is about to complete the control request. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0 Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? tcm_delayed_set_alt+0x6c/0xef0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? tcm_delayed_set_alt+0x6c/0xef0 kasan_report+0xe0/0x110 ? tcm_delayed_set_alt+0x6c/0xef0 tcm_delayed_set_alt+0x6c/0xef0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? process_one_work+0x4cb/0xb90 ? rcu_is_watching+0x20/0x50 ? tcm_delayed_set_alt+0x9/0xef0 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_tcm_delayed_set_alt+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 544: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 tcm_alloc+0x68/0x180 usb_get_function+0x36/0x60 config_usb_cfg_link+0x125/0x1b0 configfs_symlink+0x322/0x890 vfs_symlink+0xc2/0x270 filename_symlinkat+0x295/0x2f0 __x64_sys_symlinkat+0x62/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 661: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kfree+0x2f9/0x530 config_usb_cfg_unlink+0x173/0x1e0 configfs_unlink+0x1fa/0x340 vfs_unlink+0x15c/0x510 filename_unlinkat+0x2ba/0x450 __x64_sys_unlinkat+0x63/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the "emulated single-request FIFO" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as "the slot is free". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip

In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)

In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 ("fuse: fixes after adapting to new posix acl api") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.