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

A vulnerability in the Linux kernel's usb typec ps883x driver caused a kernel Oops (NULL pointer dereference) when unbinding the device. This occurred because the driver data was not properly set during probe, leading to a crash when unbinding. The issue has been fixed by adding the missing i2c_set_clientdata() call. The vulnerability affects multiple Linux kernel versions and has a medium severity score of 5.5. A patch is available as part of the Linux kernel updates.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (445a7b613694730e29915d732e3df0700d145622b279b62b0a141c76211e6f14) Package @appupdate/cdn-sync ships as a thin koffi wrapper around prebuilt Go cgo native libraries (~12MB linux.so, ~11MB darwin.dylib for x64/arm64). The JS surface exports `ProbeStart(knock)` / `ProbeStop` / `ProbeRunning` / `ProbeLastError`, where `ProbeStart` requires a caller-supplied passphrase that must match a value compiled into the native binary (per the source comment: 'knock must match the BuiltinKnock compiled into native'). The README explicitly states that endpoints and authentication are encapsulated inside the native binary so installers cannot inspect them. Strings inside the shipped binaries reference Tencent Cloud Object Storage endpoints (`cos.myqcloud.com`, `tencentcos.cn`, `https://%s.cos.%s.myqcloud.com`), indicating the worker is linked against the Tencent COS SDK with destination bucket and credentials embedded in opaque bytes. The advertised purpose (CDN static-asset sync) does not match the only exported symbol family (`Probe*`), and publisher metadata is an unfilled placeholder (`github.com/your-org/appupdate.git`, license UNLICENSED, generic `@appupdate` scope) providing no verifiable identity. The combination of a passphrase-gated activation path, deliberately hidden destination and credentials inside a shipped binary, doc-mismatched cover story, and placeholder publisher metadata is the structural shape of a covert uploader / backdoor: once an installer or downstream caller invokes `ProbeStart` with the right knock, attacker-controlled code executes on the installer's machine against a Tencent COS bucket the installer cannot see or audit.

## Summary When verifying an uploaded certificate, `lemur/certificates/verify.py` extracts the CRL Distribution Point URL and the OCSP responder URL directly from the certificate's extensions and issues outbound requests to those URLs without scheme restriction or destination allow-listing. An authenticated user holding the operator role (required by `StrictRolePermission` on `POST /certificates/upload`) can craft a certificate whose extensions point at internal services - instance metadata endpoints, internal Kubernetes API servers, RFC1918 hosts, link-local addresses - and cause the Lemur host to issue requests against those destinations during verification. ## Root Cause `lemur/certificates/verify.py`, `crl_verify`: ```python point = p.full_name[0].value # URL from CDP extension of uploaded cert ... response = requests.get(point, timeout=(3.05, 6)) # no allow-list, no destination filter ``` `lemur/certificates/verify.py`, `ocsp_verify`: ```python command = ["openssl", "x509", "-noout", "-ocsp_uri", "-in", cert_path] p1 = subprocess.Popen(command, stdout=subprocess.PIPE, ...) url, _ = p1.communicate() p2 = subprocess.Popen( ["openssl", "ocsp", "-issuer", issuer_chain_path, "-cert", cert_path, "-url", url.strip()], # attacker-controlled URL ... ) ``` In both code paths the URL flows from attacker-controlled certificate-extension content to a network sink with no validation against an allow-list of hostnames, no scheme restriction beyond rejecting LDAP via `InvalidSchema`, and no filtering of RFC1918 / link-local (169.254/16) / loopback / IPv6 ULA destinations. ## Affected Endpoints | Method | Path | Source | |---|---|---| | POST | /api/1/certificates/upload | `verify_string` → `crl_verify` / `ocsp_verify` | The bug additionally surfaces anywhere `verify_string` is invoked on attacker-influenced certificate content (sync paths, source plugin re-validation, etc.). The upload endpoint is the most direct trigger. ## Impact An operator-role attacker can: - Probe the Lemur host's internal network through outbound CRL/OCSP fetches and infer topology from response timings and error messages. - On EC2 instances without IMDSv2 enforcement, cause requests to `http://169.254.169.254/` and influence downstream behavior of components that parse the response. - Pin attacker-controlled CRLs into the unbounded module-level `crl_cache` dict (see Advisory 4c) for permanent cache poisoning - once cached, a poisoned CRL is served to every subsequent verification for the same URL. The operator-role precondition reduces severity from what an unauthenticated SSRF would warrant, but operators are still meaningfully less trusted than the host's network position. PKI workflows also routinely process third-party certificates whose extensions are not directly controlled by the operator, broadening the trigger surface beyond purely-malicious operators. ## Remediation Filter the URL before it reaches the network sink. Either: 1. Maintain an explicit allow-list of CRL/OCSP hostnames in configuration (e.g., `LEMUR_TRUSTED_CRL_HOSTS` and `LEMUR_TRUSTED_OCSP_HOSTS`) and reject anything outside the list, **or** 2. Use an SSRF-safe HTTP client wrapper that resolves the destination, rejects RFC1918 / link-local / loopback / IPv6 ULA addresses before connecting, and pins the resolved IP to defeat DNS rebinding. For OCSP, route the parsed URL through the same wrapper before passing it as `-url` to `openssl ocsp`. Additionally, bound `crl_cache` (see Advisory 4c) to prevent the SSRF vector from amplifying into a persistent cache-poisoning condition. ## Steps to Reproduce 1. Set up Lemur on an EC2 instance with IMDSv1 enabled (or any host with reachable RFC1918 services). Create an admin user and an operator-role user `eve`. 2. Generate a self-signed certificate whose extensions point at internal services: ``` cat > openssl.cnf <<EOF [req] distinguished_name = req_distinguished_name req_extensions = v3_ca prompt = no [req_distinguished_name] CN = ssrf-poc.example [v3_ca] crlDistributionPoints = URI:http://169.254.169.254/latest/meta-data/iam/security-credentials/ authorityInfoAccess = OCSP;URI:http://169.254.169.254/latest/meta-data/ EOF openssl req -x509 -newkey rsa:2048 -keyout ssrf.key -out ssrf.crt \ -days 365 -nodes -config openssl.cnf -extensions v3_ca ``` 3. On the Lemur host, start a packet capture filter for the target address before submitting the cert: ``` sudo tcpdump -nni any host 169.254.169.254 ``` 4. As `eve`, upload the malicious certificate: ``` BODY=$(cat ssrf.crt | sed ':a;N;$!ba;s/\n/\\n/g') curl -X POST https://lemur.local/api/1/certificates/upload \ -H "Authorization: Bearer <eve_jwt>" \ -H "Content-Type: application/json" \ -d "{ \"name\": \"ssrf-poc\", \"body\": \"$BODY\", \"ch

A flaw was found in Keycloak. A realm administrator with the "manage-realm" role can exploit this vulnerability by submitting an arbitrary filesystem path as a keystore parameter when creating a key provider component. This allows the administrator to probe arbitrary filesystem paths, determining which files exist and are readable by the Keycloak process. This information disclosure could be used to identify high-value targets for follow-on attacks.

In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() timeout in probe rsu_send_msg() can return -ETIMEDOUT when wait_for_completion_interruptible_timeout() fires while the SMC call is still pending. In stratix10_rsu_probe(), the error paths for COMMAND_RSU_DCMF_VERSION, COMMAND_RSU_DCMF_STATUS, COMMAND_RSU_MAX_RETRY and COMMAND_RSU_GET_SPT_TABLE call stratix10_svc_free_channel() - which sets chan->scl to NULL - but then fall through and queue the next request on the same channel. The next svc kthread that runs will dereference pdata->chan->scl in its receive callback path, triggering a NULL pointer dereference identical to the one fixed by commit c45f7263100c ("firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled") for the COMMAND_RSU_STATUS path. Apply the same cleanup pattern to the remaining failure paths: remove the async client, free the channel, and return early so no further messages are queued on a channel whose scl has been cleared. While at it, clean up stratix10_rsu_probe() in two ways without changing behavior: - Drop redundant zero-initialization of fields already cleared by devm_kzalloc(): client.receive_cb, status.* and spt0/1_address (INVALID_SPT_ADDRESS is 0x0). - Replace five identical 3-line error-cleanup blocks (stratix10_svc_remove_async_client() + stratix10_svc_free_channel() + return ret) with goto labels (remove_async_client, free_channel), matching the standard kernel resource-unwinding pattern and making it easier to extend the probe sequence without forgetting matching cleanup. Also move init_completion() next to mutex_init() so sync-primitive initialization is grouped before anything that could trigger a callback. --- v2: Add a minor clean-up of the function stratix10_rsu_probe() to have a centralize exit for all the rsu_send_async_msg() and rsu_send_msg().

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)

In the Linux kernel, the following vulnerability has been resolved: drm/xe/display: fix oops in suspend/shutdown without display The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probe_display. It gets set to false if there's no display after intel_display_device_probe(). However, the display may also be disabled via fuses, detected at a later time in intel_display_device_info_runtime_init(). In this case, the xe driver does for_each_intel_crtc() on uninitialized mode config in xe_display_flush_cleanup_work(), leading to a NULL pointer dereference, and generally calls display code with display info cleared. Check for intel_display_device_present() after intel_display_device_info_runtime_init(), and reset xe->info.probe_display as necessary. Also do unset_display_features() for completeness, although display runtime init has already done that. This will need to be unified across all cases later. Move intel_display_device_info_runtime_init() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases. Note #1: The xe driver has no business doing low level display plumbing like for_each_intel_crtc() to begin with. It all needs to happen in display code. Note #2: The actual bug is present already in commit 44e694958b95 ("drm/xe/display: Implement display support"), but the oops was likely introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete"). (cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)

A vulnerability in the Linux kernel's devlink subsystem was fixed that addressed a memory relation release issue. The flaw occurs when devlink instances acquire nested relations before registration but fail during probe, causing a memory relation leak. This leak happens because the normal release path via devl_unregister() is bypassed. The fix ensures that any pending relations are released during devlink_free() as well. The vulnerability affects specific Linux kernel versions and has been resolved in later fixed releases.

CVE-2026-53232 is a high-severity vulnerability in the Linux kernel affecting version 5.5. It involves improper cleanup of the SFP (Small Form-factor Pluggable) upstream field when PHY probing fails, which can lead to use of a dangling pointer during SFP events. This flaw was fixed by ensuring sfp_bus_del_upstream() is called on probe failure to prevent dangling references.

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix listxattr handling when the buffer is full [BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis.

The npm package @gleamkit/probe version 0.0.1 is identified as containing malicious code. Although automated analysis found no suspicious behaviors such as remote fetches or credential scraping, the package is flagged by a malware advisory as fully compromising any system where it is installed. Removal of the package does not guarantee elimination of all malicious software, and any secrets or keys on the affected system should be rotated immediately from a different machine.

# Vulnerability Central Dogma's Git mirror SSH client installs an Apache MINA SSHD `ServerKeyVerifier` lambda that returns `true` unconditionally for every outbound SSH connection used by `git+ssh://` mirrors. The accompanying lines disable the `known_hosts` and `~/.ssh/config` fallbacks, and a repo-wide search confirms that no host-key pinning mechanism (no `acceptedHostKeys`, `knownHosts`, `KnownHostsServerKeyVerifier`, `StaticServerKeyVerifier`, or `RequiredServerKeyVerifier`) exists anywhere in `server-mirror-git/`. Operators have no opt-in way to enable verification. Every outbound mirror connection blindly trusts whatever host key the remote presents. ## Evidence File: `server-mirror-git/src/main/java/com/linecorp/centraldogma/server/internal/mirror/SshGitMirror.java` Lines 143-160 (especially 149) on branch `main` @ commit `d64a5151`: ```java private SshClient createSshClient() { final ClientBuilder builder = ClientBuilder.builder(); // Do not use local file system. builder.hostConfigEntryResolver(HostConfigEntryResolver.EMPTY); // line 146 builder.fileSystemFactory(NoneFileSystemFactory.INSTANCE); // line 147 // Do not verify the server key. builder.serverKeyVerifier((clientSession, remoteAddress, serverKey) -> true); // line 149 ... } ``` Verification: - Read confirmed on 2026-05-21 against `main` @ `d64a5151`. - A multi-agent code audit verified that no operator-facing pinning field exists on `SshKeyCredential`, `PasswordCredential`, or `MirrorContext`. - Exploit PoC reproduced locally with a `paramiko`-based fake SSH server bound to 127.0.0.1. The fake server presents an ephemeral RSA host key never seen before; the Central Dogma mirror client accepts the connection and proceeds to authentication, logging the offered username and public-key fingerprint. A correctly hardened SSH client would refuse the connection before reaching the authentication phase. - Full PoC artifacts (read-only, loopback-only) at `~/centraldogma-poc/C1_ssh_hostkey_bypass/` on the reporter's workstation. ## Impact Threat model: An on-path attacker on the corporate network — ARP spoofing on the LAN, internal DNS poisoning, malicious internal DNS overriding `github.com` or the configured internal git hostname, BGP hijack, sidecar/CNI compromise in Kubernetes, or any process able to answer TCP on the resolved IP. No Central Dogma account required; only network position. 1. **Direction `LOCAL_TO_REMOTE`**: the attacker impersonating the remote git server receives the entire mirrored repository contents over the SSH session. Central Dogma is a configuration store, so this typically exfiltrates DB credentials, third-party API keys, certificates, feature flags, and any other secret configuration committed to mirrored repositories. 2. **Direction `REMOTE_TO_LOCAL`**: the attacker can serve arbitrary commits which Central Dogma materializes into the local repo and then broadcasts to every subscribing microservice via the watch API. This is a supply-chain root-of-trust compromise across all downstream services consuming Central Dogma configuration. 3. **Credential theft chain with finding H2** (mirror credentials are not bound to a hostname): an SSH key or access token configured for `github.com` can be captured by the attacker's fake server and replayed against the real upstream, extending impact beyond Central Dogma itself. Scope is `Changed` (CVSS) because exploitation alters trust assumptions of every downstream client of Central Dogma, not just Central Dogma itself. ## How to fix 1. Add an `acceptedHostKeys: List<String>` field to `SshKeyCredential` and `PasswordCredential` (or to `MirrorContext`). Values are SHA-256 fingerprints of trusted remote SSH server host keys, e.g. `SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8`. 2. Replace the accept-all lambda at `SshGitMirror.java:149` with a verifier that computes the SHA-256 fingerprint of the presented host key and compares it against the credential's allowlist using a constant-time comparison. 3. Refuse to connect when `acceptedHostKeys` is empty — fail-closed. Do not implement implicit TOFU. 4. Optionally provide an admin-only `dogma mirror probe-host-key <remote>` tool that performs a single audited connection, prints the server's fingerprint, and prompts the operator to add it to the credential. This makes TOFU an explicit, audited operation. 5. Update `SshGitMirrorTest.java` and `it/mirror/*` tests to pin a test fingerprint or use the explicit trust-once tool, so the regression cannot silently return.

Cap-go before 12.128.2 contains an information disclosure vulnerability in the OPTIONS /build/upload/:jobId/* endpoint that allows unauthenticated attackers to enumerate valid builder job IDs through observable response discrepancies. Attackers can probe the endpoint without authentication to distinguish valid job IDs from invalid ones and generate sustained unauthenticated traffic for resource consumption.

gonic is a music streaming server / free-software subsonic server API implementation. The maintainer's fix in commit `6dd71e6a3c966867ef8c900d359a7df75789f410` added an ownership check based on `playlist.UserID`. However, `playlist.UserID` is derived from the first path segment of the attacker-controlled playlist ID, with no path containment on the resolved file path. Any authenticated Subsonic user can therefore bypass the ownership check and read any other user's playlist, delete any other user's playlist, and probe arbitrary file paths on the host for existence/readability. This is a bypass of the boundary the `6dd71e6` fix is trying to enforce; it is closely related to the original GONIC-1 IDOR but uses a different primitive (path traversal in the `id` parameter rather than direct cross-user access). Commit 0824bed88f6bbc490ba28bf09d28e5dfeb07b445 in version 0.21.0 fixes the issue.