Search: ye.call

Since April 2026, threat actors operating under O-UNC-066 have deployed a sophisticated vishing campaign targeting Microsoft 365 passkey enrollment. Attackers register domains containing 'passkey' and call victims to convince them to register new passkeys. Victims are directed to operator-controlled phishing kits that mimic Microsoft's enrollment process while attackers simultaneously register their own passkeys in victim accounts. The kit uses real-time polling and adapts to various MFA requirements including TOTP, push notifications, and SMS OTP. Targeted organizations span food and beverage, technology, healthcare, automotive, construction, and aviation industries. The campaign leverages Microsoft's legitimate passkey registration campaigns as a pretext, with primary motivation being data extortion through the Pink data leak site. Infrastructure is hosted on DDoS-Guard and IQWeb FZ-LLC.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (7a6dd276f30733865042d929d52211583fa63323b5118d26e5cbe6219137f86d) Package name 'tailwind-core' impersonates the legitimate 'tailwindcss' package, using a mimicked monorepo directory ('packages/tailwind-core') and reusing tailwindlabs/tailwindcss CI badges plus links to the real tailwindcss download counts in README. The bundled library entrypoints dist/lib.mjs and dist/lib.js contain a hidden async function invoked from the Tailwind plugin factory that fires when the compiler runs during a build. After a Date.now() gate set to approximately July 2026 (timestamp 17836416e5), the code collects host reconnaissance (os.hostname, os.homedir, os.platform, os.arch, os.cpus().length, os.totalmem), derives a stable equip_id hash, and registers the host with an attacker-controlled Google Apps Script deployment via an 'addNewEquipment' call. It then enters an infinite polling loop that mints Google OAuth access tokens from a hardcoded refresh token and client_id/client_secret embedded in the bundle, retrieves base64+JSON commands from https://script.googleapis.com/v1/scripts/AKfycbyjrAVcSQB2V6XNzgYK8J0gGyx0c_ZpC0y4rFzq1IGUPu7zx7guLszZDVlcsfDzXVz3QA:run, and executes them via new Function(...), yielding arbitrary remote code execution on every installer machine running builds after the activation date. The delayed-activation timestamp gate is a time-bomb designed to evade publish-time scanning. ## Source: ghsa-malware (13f32ca9fa359af39fdc94870029079c18f805e941572fe607e6a5238b30a429) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

## Summary Authorization for scoped (agent) MCP callers is enforced **inline, per tool**, and is applied inconsistently — several mutating tools silently omit the ancestry/workspace check that their siblings perform. Because the MCP server authenticates all outbound gRPC with the full server API key and the backend gRPC handlers perform **no caller-based authorization**, the MCP tool layer is the *sole* authorization boundary. A malicious or prompt-injected scoped agent can therefore perform cross-task and cross-session operations it should not be allowed to (an IDOR / privilege-boundary bypass). This advisory bundles the audit's **Systemic Pattern A** findings: **F2, F6, F7, F12** (and the duplicate F19). ## Affected versions `@grackle-ai/mcp` (with `@grackle-ai/plugin-core` / `@grackle-ai/auth`) at **0.132.1** and earlier. ## Root cause - `mcp-server.ts:111-127` (`createGrpcClients`) sets `Authorization: Bearer ${apiKey}` (the full server key) on every outbound gRPC call. - Backend handlers (`updateTask`, `deleteTask`, `resumeTask`, `killAgent`, `getTask` in `plugin-core`) take only the request message — no `AuthContext` — and act on whatever ID is passed. - Therefore scope must be enforced in each MCP tool handler. Some call `assertCallerIsAncestor` (`task_complete`, `task_start`, `session_attach`, `session_send_input`); their destructive siblings do not. New tools that forget the check **fail open**. ## F2 — task_update / task_delete / task_resume bypass ancestry (High) **Location:** `packages/mcp/src/tools/task.ts:226` (task_update), `:393` (task_delete), `:465` (task_resume). These accept an arbitrary `taskId` with only a `ROOT_TASK_ID` special-case and no `assertCallerIsAncestor`. The central dispatcher hardcodes its workspace gate to `name === "task_show"`, and these tools' Zod schemas have no `workspaceId` field (so the blanket injection is stripped). They are not in `DEFAULT_SCOPED_MCP_TOOLS` but **are** in the shipped `ORCHESTRATOR_MCP_TOOLS` / `ADMIN_MCP_TOOLS` presets. **Exploit:** a scoped agent under the orchestrator persona learns a sibling/parent/cross-workspace task ID (via `task_list`/`task_search`), then `task_delete {taskId: <victim>}` (permanently destroys another agent's or the human parent's work) or `task_update` to flip a sibling to `complete`/`failed` or rewrite its dependency DAG and budgets. ## F6 — session_kill / session_resume bypass ancestry (Medium) **Location:** `packages/mcp/src/tools/session.ts:95` (session_resume), `:178` (session_kill). Call `client.killAgent` / `client.resumeAgent` directly with no auth context, unlike `session_attach`/`session_send_input`. `session_kill` is in the orchestrator preset. **Exploit:** cross-session SIGKILL DoS against a sibling agent or the root orchestrator; foreign session resume. ## F7 — Workspaceless scoped token fails open to all workspaces (Medium) **Location:** `packages/mcp/src/mcp-server.ts:565-600`. The per-task cross-workspace check (`task_show` block) is gated on `authContext.workspaceId` being truthy. A task created without a workspace (a supported config) mints a scoped token with `pid: ""` → `workspaceId: undefined`, so the check is skipped and the injected `workspaceId` becomes `""`, which the backend treats as "all workspaces." **Exploit:** a malicious agent in a workspaceless session calls `task_list` (no args) → reads every task in every workspace, then `task_show {taskId}` cross-workspace (title/description/branch/review-notes). `schedule_show` (in the default scoped allowlist) resolves by ID with no workspace check. Read-only cross-workspace disclosure. ## F12 — Scoped-token revocation is dead code (Low) **Location:** `packages/auth/src/scoped-token.ts:23,142-149`. The consuming check is wired (`auth-middleware.ts:90-92`), but `revokeTask()` is **never called outside tests** — no task-abort/stop flow invokes it — and the backing `revokedTasks` Map is in-memory only (lost on restart). A compromised agent that exfiltrated its scoped token keeps authenticating for the full 24h TTL regardless of task lifecycle. ## Remediation - **Systemic fix:** enforce scope **centrally** in the `CallToolRequest` dispatcher (`mcp-server.ts`) via a per-tool `targetTaskIdArg` / `targetSessionIdArg` descriptor so any tool that targets a task/session **fails closed** unless the caller is an ancestor (or self). - Immediately, add `assertCallerIsAncestor` (or self-or-ancestor) to `task_update`, `task_delete`, `task_resume`, `session_kill`, `session_resume`, mirroring `task_complete`/`task_start`. - F7: do **not** fail open on empty `workspaceId` — treat a scoped non-root caller with no workspace as having access to *no* workspace; apply the `task_show` membership check whenever the caller is scoped and not `ROOT_TASK_ID`; add a per-id membership check to `schedule_show`. - F12: wire `revokeTask()` into task-abort/stop flows with SQLite-backed persistence (like channel-grant revocation), or remove the dead API and document

### Summary `SQLChatAgent` in `langroid` ships a `_validate_query` defense-in-depth layer whose `_DANGEROUS_SQL_PATTERNS` regex blocklist enumerates dangerous SQL primitives by specific function name. The list misses the canonical PostgreSQL filesystem-disclosure family `pg_read_file()`, `pg_stat_file()`, `pg_ls_logdir()`, `pg_ls_waldir()`, `pg_current_logfile()` (and similar `SELECT`-shaped functions in the same family). It also leaves SQL Server `OPENDATASOURCE` and SQLite `ATTACH '<file>' AS x` (DATABASE keyword omitted) unblocked. An attacker able to shape the LLM's generated SQL (directly via prompt input or transitively via prompt-injection in data the LLM ingests) can read arbitrary files from the PostgreSQL host through ordinary `SELECT` queries, even with the agent's strict default configuration (`allow_dangerous_operations=False`, `allowed_statement_types=['SELECT']`). The payloads survive the statement-type allowlist (each is a `SELECT`) and pass through the regex blocklist (none of the function names match), then reach the live SQLAlchemy engine via `SQLChatAgent.run_query`. ### Affected versions `langroid` `<= 0.63.0` (latest at the time of this report; PyPI release 2026-05-27). The vulnerable code path is `langroid/agent/special/sql/sql_chat_agent.py::_validate_query`, which consults the module-level `_DANGEROUS_SQL_PATTERNS` literal at `sql_chat_agent.py:113-141`. ### Privilege required Any caller able to influence the LLM-generated `RunQueryTool.query` string that reaches `SQLChatAgent.run_query`. In a typical deployment this is any client of a SQLChatAgent-backed service, or any upstream data source whose content the LLM is asked to read and summarise. No PostgreSQL credentials are required from the attacker; the agent holds them. ### Vulnerable code `langroid/agent/special/sql/sql_chat_agent.py:113-141` (the `_DANGEROUS_SQL_PATTERNS` literal) and `sql_chat_agent.py:546-615` (the `_validate_query` method that consults it): ```python # sql_chat_agent.py:113 _DANGEROUS_SQL_PATTERNS: List["re.Pattern[str]"] = [ re.compile(r"\bcopy\b[\s\S]*\bprogram\b", re.IGNORECASE), re.compile(r"\bpg_read_server_files?\b", re.IGNORECASE), re.compile(r"\bpg_read_binary_file\b", re.IGNORECASE), re.compile(r"\bpg_ls_dir\b", re.IGNORECASE), re.compile(r"\blo_(import|export)\b", re.IGNORECASE), re.compile(r"\binto\s+(outfile|dumpfile)\b", re.IGNORECASE), re.compile(r"\bload_file\s*\(", re.IGNORECASE), re.compile(r"\bload\s+data\b", re.IGNORECASE), re.compile(r"\bload_extension\s*\(", re.IGNORECASE), re.compile(r"\battach\s+database\b", re.IGNORECASE), re.compile(r"\bxp_cmdshell\b", re.IGNORECASE), re.compile(r"\bsp_oacreate\b", re.IGNORECASE), re.compile(r"\bsp_oamethod\b", re.IGNORECASE), re.compile(r"\bopenrowset\b", re.IGNORECASE), re.compile(r"\bbulk\s+insert\b", re.IGNORECASE), re.compile( r"\bcreate\s+(or\s+replace\s+)?(function|procedure|trigger)\b", re.IGNORECASE, ), re.compile(r"\bcreate\s+extension\b", re.IGNORECASE), ] ``` The blocklist is a list of `\b<exact-token>\b` literals. PostgreSQL ships several near-name functions on the same primitive that none of these match: | Function | What it returns | Matched by blocklist? | |---|---|---| | `pg_read_server_file('/path')` | file contents | yes (`pg_read_server_files?`) | | `pg_read_binary_file('/path')` | binary contents | yes | | `pg_ls_dir('/path')` | directory listing | yes | | `pg_read_file('/path')` | file contents | **no** (no `_server_` infix) | | `pg_stat_file('/path')` | size, mtime, ctime, atime, isdir | **no** | | `pg_ls_logdir()` | filenames in PostgreSQL log dir | **no** | | `pg_ls_waldir()` | WAL filenames and sizes | **no** | | `pg_ls_tmpdir()` | temp-dir listing | **no** | | `pg_ls_archive_statusdir()` | archive-status directory listing | **no** | | `pg_current_logfile()` | active server log path | **no** | Each of these is a `SELECT`-shaped function call. They pass the `sqlglot_exp.Select`-only statement-type allowlist applied at `sql_chat_agent.py:583-614`, then evade the regex blocklist (their names contain no token the blocklist enumerates), then reach the SQLAlchemy `session.execute(text(query))` sink inside `SQLChatAgent.run_query` (line 631 onwards). Two non-PostgreSQL secondary gaps with the same regex-enumeration shape: - The SQLite pattern `\battach\s+database\b` requires the literal `DATABASE` keyword. Per the SQLite grammar (https://www.sqlite.org/lang_attach.html) the keyword is optional: `ATTACH '/path/to/db' AS x` is valid syntax and matches no entry in the blocklist. Whether the agent rejects this via the statement-type allowlist depends on how the configured `sqlglot` dialect parses it; on PostgreSQL dialect parsing fails (sqlglot returns no `Select`) and the statement-type check rejects, but a SQLite-dialect SQLChatAgent (`database_uri="sqlite:///..."`) returns the statement as `sqlglot_exp.Attach`, whi

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. One of them, `connectionInfo` is meant to provide the necessary details to connect to a camera. The handler associated with this command that we call`handle_connection_info` contains multiple instances of string copy that can overflow. The function `handle_connect_info` copies attacker-controlled JSON strings into fixed-size buffers using manual byte-by-byte loops that do not enforce length limits. #### Buffer Overflow in ip field

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. One of them, `connectionInfo` is meant to provide the necessary details to connect to a camera. The handler associated with this command that we call`handle_connection_info` contains multiple instances of string copy that can overflow. The function `handle_connect_info` copies attacker-controlled JSON strings into fixed-size buffers using manual byte-by-byte loops that do not enforce length limits. #### Buffer Overflow in key field

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. One of them, `connectionInfo` is meant to provide the necessary details to connect to a camera. The handler associated with this command that we call`handle_connection_info` contains multiple instances of string copy that can overflow. The function `handle_connect_info` copies attacker-controlled JSON strings into fixed-size buffers using manual byte-by-byte loops that do not enforce length limits. #### Buffer Overflow in password field (key present)

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. One of them, `connectionInfo` is meant to provide the necessary details to connect to a camera. The handler associated with this command that we call`handle_connection_info` contains multiple instances of string copy that can overflow. The function `handle_connect_info` copies attacker-controlled JSON strings into fixed-size buffers using manual byte-by-byte loops that do not enforce length limits. #### Buffer Overflow in username field (key present)

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. One of them, `connectionInfo` is meant to provide the necessary details to connect to a camera. The handler associated with this command that we call`handle_connection_info` contains multiple instances of string copy that can overflow. The function `handle_connect_info` copies attacker-controlled JSON strings into fixed-size buffers using manual byte-by-byte loops that do not enforce length limits. #### Buffer Overflow in password field (no key present)

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. One of them, `connectionInfo` is meant to provide the necessary details to connect to a camera. The handler associated with this command that we call`handle_connection_info` contains multiple instances of string copy that can overflow. The function `handle_connect_info` copies attacker-controlled JSON strings into fixed-size buffers using manual byte-by-byte loops that do not enforce length limits. #### Buffer Overflow in username field (no key present)

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. The Websocket server can accept various commands coming from localhost. Many of the commands will take an `index` value that is then used to access various arrays to enter critical sections, perform various actions via function calls, etc. However the `index` value is usually not checked for valid range, and as such it can be used to access multiple arrays out-of-bound. ### saveVideo command index-out-of-bound When sending the `saveVideo` command, the `index` field is extracted from the websocket message [1]. Then without checking the range of the index, it is used to trigger a CriticalSection ([2]) and releases it [3]. The release function call ([3]) is executed using a function pointer which will be read out of bounds potentially leading to code execution: v6 = get_entry(a2, "index"); result = json_is_value_int(v6); if ( (_BYTE)result ) { v8 = get_entry(a2, "index"); index = json_value_to_int(&v8->value); // [1] result = CCriticalSection::EnterCritSection(&this->crit_sections[index]); //[2] if ( result ) { if ( this->array_of_IPCams[index] ) { if ( this->array_of_IPCams[index]->field_20 ) do_PostMessageA((CViewer *)this->array_of_IPCams[index], 0x111u, 0x139Fu, v11); } return (*(int (__thiscall **)(CCriticalSection *))(this->crit_sections[index].vtbl + 20))(&this->crit_sections[index]); //[3] } }

GeoWebPlayer (also called "Web Plugin" in the GV-VMS documentation and "WS Player" for VMS-Cloud) is an addon that can be installed with various GeoVision software (GV-VMS, GV-Cloud, ...). It creates a websocket server that expands the capabilities of the various web-interfaces provided by the GeoVision software and may be necessary for them to function properly. In order to access the websocket server, no authentication is required. As such, any malicious website can attempt to open a connection to the server and potentially access sensitive APIs. In particular, it's possible to call a combination of the `create` method and `getScreenCapture` to retrieve the content of the user's screen.

runc is a CLI tool for spawning and running containers according to the OCI specification. In versions prior to 1.3.6, 1.4.0-rc.1, 1.4.0-rc.12, 1.5.0-rc.1, and 1.5.0-rc.1, when setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory. This issue is not exploitable under Docker, because Docker creates a top-level read-only layer that masks any malicious /dev symlink present in the container image — unlike some other Linux container tooling, whose higher-level runtimes built on runc remain exposed to exploitation via a malicious image. This issue has been fixed in versions 1.3.6, 1.4.3 and 1.5.0.

The Gentlemen ransomware group, which emerged in July 2025, employed a zero-day vulnerability in a bring-your-own-vulnerable-driver (BYOVD) attack to disable endpoint detection and response systems. During an incident investigated in early April, the group leveraged an obscure third-party driver named ktapi.sys from Kontron to bypass security protections. The sophisticated exploit chains multiple advanced techniques to navigate Windows exploit mitigations, including bypassing Supervisor Mode Access Prevention and Supervisor Mode Execution Prevention. The toolkit enables the attackers to call privileged kernel mode functions from user mode processes, ultimately terminating EDR processes including Windows Defender, ESET, Palo Alto Cortex XDR, and SentinelOne. The vulnerability had no prior public documentation and was previously absent from vulnerable driver blocklists.

Malicious npm package published as part of a coordinated DeFi-themed infostealer campaign. `console-fmt-cli` uses a side-loader technique: it declares `decimal-format-core >=3.0` as a dependency, which contains a dropper that executes at install time via a `postinstall` hook. The dropper fetches a second-stage infostealer from a remote C2 (`logstream-api.online`) that harvests cryptocurrency wallet vaults (MetaMask, Phantom, Solflare, OKX, Coinbase, TrustWallet, Backpack, TronLink), browser cookies and credentials, SSH keys, AWS credentials, `.npmrc` tokens, Docker config, shell history, and password manager databases. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (62d4aa3c5f7523f4a10d37346a6eaa228940d76f797e13b6d2010385e81e4331) On every call to createLogger (the package's documented entrypoint), logger.js resolves the peer dependency decimal-format-core's private scripts/install-check.cjs path and invokes runRuntimeProjectSync() via setImmediate, wrapped in a try/catch that suppresses all errors. The README describes decimal-format-core as an optional formatting dependency, yet the logger unconditionally reaches into that dependency's internal scripts/ directory and executes a runtime function on ordinary library use. The trigger function is named queueRuntimeProjectSync and the invoked file is named install-check.cjs, both consistent with a cover story that hides script execution from the consumer. This package itself contains no exfiltration or network calls; its role is to act as a loader stub that shifts execution into decimal-format-core, whose install-check.cjs code determines the actual payload behavior.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (3975a0998bf76dddc25f0138b1d4b408bb06304b3203dc1e62e0110b2b56425f) InLifeGram distributes a modified copy of the `pyrogram` Telegram client library and installs it into the top-level `pyrogram` import namespace, so `import pyrogram` after installation resolves to this fork. The fork's Client start path has been modified to lazily import a sibling module (`from. import app as secret`) and, when the authenticated account is a bot (`self.me.is_bot`), call `secret.init(self)` wrapped in a bare `except Exception: pass`. The call hands the fully authenticated client object — containing the bot token, api_id/api_hash, and MTProto auth_key — to undocumented code. The receiving `app.py` module consists of a single `exec(zlib.decompress(base64.b85decode(b'...')).decode())` over an ~11KB opaque blob, with no other functionality and an Indonesian-language header threatening anyone who removes 'credits'. The multi-layer obfuscation (base85 → zlib → exec), the silent invocation on bot authentication, and the bare-except suppression are the canonical shape of a session/token-stealing backdoor. README links a sibling project `VLife-Gram` by the same author, indicating a family of trojanized forks. Any program that installs InLifeGram and runs a Pyrogram bot will silently surrender its bot session to the hidden payload on every successful login. ## Source: kam193 (9e2d3483845391abac4b854096ffc1c7767818f9e2b02486d969ee2be0638dc9) The modified version of a Telegram bot library. The obfuscated code, launched when the user starts their own bot application, attaches malicious backdoor commands to the Telegram bot. They allow hardcoded users to execute any commands in the bot's environment. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-06-inlifegram Reasons (based on the campaign): - clones-real-package - obfuscation - The package contains code to execute remote commands (probably limited to a specific set) on the victim's machine. - rat - target:telegram - action-hidden-in-lib-usage - backdoor

In the Linux kernel, the following vulnerability has been resolved: drm/gem: Try to fix change_handle ioctl, attempt 4 [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. We also didn't have an igt merged for the original ioctl, which is a big no-go. This was attempted to address off-list in the original bugfix, and amd QA people claimed the bug was fixed now. Very clearly that's not the case. Here's my attempt to sort this out: - Rename the local variable to new_handle, the old aliasing with args->handle is just too dangerously confusing. - Merge the gem obj lookup with the two-stage idr_replace so that we avoid getting ourselves confused there. - This means we don't have a surplus temporary reference anymore, only an inherited from the idr. A concurrent gem_close on the new_handle could steal that. Fix that with the same two-stage approach create_tail uses. This is a bit overkill as documented in the comment, but I also don't trust my ability to understand this all correctly, so go with the established pattern we have from other ioctls instead for maximum paranoia. - Adjust error paths. I've tried to make the error and success paths common, because they are identical except for which handle is removed and on which we call idr_replace to (re)install the object again. But that made things messier to read, so I've left it at the more verbose version, which unfortunately hides the symmetry in the entire code flow a bit. - While at it, also replace the 7 space indent with 1 tab. And finally, because I flat out don't trust my abilities here at all anymore: - Disable the ioctl until we have the igt situation and everything else sorted out on-list and with full consensus. v2: Sashiko noticed that I didn't handle the error path for idr_replace correctly, it must be checked with IS_ERR_OR_NULL like in gem_handle_delete. So yeah, definitely should just the existing paths 1:1 because this is endless amounts of tricky. Also add the Fixes: line for the original ioctl, I forgot that too.

In the Linux kernel, the following vulnerability has been resolved: Revert "wireguard: device: enable threaded NAPI" This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream. We have had three independent production user reports in combination with Cilium utilizing WireGuard as encryption underneath that k8s Pod E/W traffic to certain peer nodes fully stalled. The situation appears as follows: - Occurs very rarely but at random times under heavy networking load. - Once the issue triggers the decryption side stops working completely for that WireGuard peer, other peers keep working fine. The stall happens also for newly initiated connections towards that particular WireGuard peer. - Only the decryption side is affected, never the encryption side. - Once it triggers, it never recovers and remains in this state, the CPU/mem on that node looks normal, no leak, busy loop or crash. - bpftrace on the affected system shows that wg_prev_queue_enqueue fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer's rx_queue is reached. - Also, bpftrace shows that wg_packet_rx_poll for that peer is never called again after reaching this state for that peer. For other peers wg_packet_rx_poll does get called normally. - Commit db9ae3b ("wireguard: device: enable threaded NAPI") switched WireGuard to threaded NAPI by default. The default has not been changed for triggering the issue, neither did CPU hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always return valid online CPU in wg_cpumask_choose_online()")). - The issue has been observed with stable kernels of v5.15 as well as v6.1. It was reported to us that v5.10 stable is working fine, and no report on v6.6 stable either (somewhat related discussion in [0] though). - In the WireGuard driver the only material difference between v5.10 stable and v5.15 stable is the switch to threaded NAPI by default. [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/ Breakdown of the problem: 1) skbs arriving for decryption are enqueued to the peer->rx_queue in wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer. 2) The latter only moves the skb into the MPSC peer queue if it does not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an atomic counter via wg_prev_queue_enqueue. 3) In case enqueueing was successful, the skb is also queued up in the device queue, round-robin picks a next online CPU, and schedules the decryption worker. 4) The wg_packet_decrypt_worker, once scheduled, picks these up from the queue, decrypts the packets and once done calls into wg_queue_enqueue_per_peer_rx. 5) The latter updates the state to PACKET_STATE_CRYPTED on success and calls napi_schedule on the per peer->napi instance. 6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks on the peer->rx_queue. It will wg_prev_queue_dequeue if the queue->peeked skb was not cached yet, or just return the latter otherwise. (wg_prev_queue_drop_peeked later clears the cache.) 7) From an ordering perspective, the peer->rx_queue has skbs in order while the device queue with the per-CPU worker threads from a global ordering PoV can finish the decryption and signal the skb PACKET_STATE_CRYPTED out of order. 8) A situation can be observed that the first packet coming in will be stuck waiting for the decryption worker to be scheduled for a longer time when the system is under pressure. 9) While this is the case, the other CPUs in the meantime finish decryption and call into napi_schedule. 10) Now in wg_packet_rx_poll it picks up the first in-order skb from the peer->rx_queue and sees that its state is still PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e ---truncated---

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.7.12, when Deno was run in BYONM mode (nodeModulesDir: "manual"), the module resolver did not validate that a package's resolved entrypoint stayed within its node_modules/<pkg>/ directory. A malicious package.json whose main field contained .. segments was able to resolve to an arbitrary path on disk, and the resolver then read that file without consulting the --allow-read allowlist. This let a require("evil-pkg") call return the contents of a file that a direct Deno.readTextFileSync(...) call would have been blocked from reading. This vulnerability is fixed in 2.7.12.

### Summary `parse_form()` did not validate the `Content-Length` header before using it to bound its chunked read of the request body. A negative `Content-Length` turned the bounded read into a read-until-EOF, so the entire body was loaded into memory in a single read instead of in fixed-size chunks. ### Details `parse_form()` reads the input stream in chunks, never reading more than the remaining `Content-Length` at a time. The per-chunk size is computed as `min(content_length - bytes_read, chunk_size)`. The header value was parsed to an integer without checking its sign, so a `Content-Length` of `-1` made this expression negative, and `input_stream.read(-1)` reads until end of stream. The intended bounded, chunked read therefore collapsed into a single unbounded read of the whole stream. The amount read is still bounded by what the client actually sends. ### Impact This only affects code that calls `parse_form()` directly with a `Content-Length` header taken from attacker-controlled input and without normalizing a negative value first. No known package is affected: * Starlette and FastAPI drive `MultipartParser` directly from the ASGI `receive()` stream and do not call `parse_form()`. * Known `parse_form()` consumers either do not forward `Content-Length` to it, recompute it from the already-read body, or run behind a layer (such as Werkzeug) that normalizes a negative `Content-Length` to `0`. The realistic exposure is limited to bespoke WSGI or `http.server` handlers that forward raw client headers into `parse_form()`. In that case a crafted request buffers the body in memory at once, degrading availability under concurrent requests rather than causing a complete denial of service. ### Mitigation Upgrade to version `0.0.31` or later, which rejects a negative `Content-Length` with a `ValueError` before reading the stream.