PX4 autopilot is a flight control solution for drones. Prior to 1.17.0-rc2, the BST telemetry probe writes a string terminator using a device-provided length without bounds. A malicious BST device can report an oversized dev_name_len, causing a stack overflow in the driver and crashing the task (or enabling code execution). This vulnerability is fixed in 1.17.0-rc2.
A vulnerability has been found in psi-probe PSI Probe up to 5.3.0. This affects the function lookup of the file psi-probe-core/src/main/java/psiprobe/tools/Whois.java of the component Whois. The manipulation leads to server-side request forgery. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
A flaw has been found in psi-probe PSI Probe up to 5.3.0. The impacted element is the function handleRequestInternal of the file psi-probe-core/src/main/java/psiprobe/controllers/sessions/ExpireSessionsController.java of the component Session Handler. Executing a manipulation can lead to denial of service. The attack can be launched remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
A vulnerability was detected in psi-probe PSI Probe up to 5.3.0. The affected element is an unknown function of the file psi-probe-core/src/main/java/psiprobe/controllers/sessions/RemoveSessAttributeController.java of the component Session Attribute Handler. Performing a manipulation results in improper access controls. The attack can be initiated remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
A flaw was found in the FTP GVfs backend. A malicious FTP server can exploit this vulnerability by providing an arbitrary IP address and port in its passive mode (PASV) response. The client unconditionally trusts this information and attempts to connect to the specified endpoint, allowing the malicious server to probe for open ports accessible from the client's network.
This release of the Red Hat build of OpenTelemetry provides new features, security improvements, and bug fixes.
Breaking changes:
* The deprecated OpenCensus Receiver, which provided backward compatibility with the OpenCensus project for easier migration of instrumented codebases, is removed and is no longer supported. You can use the OpenTelemetry Protocol (OTLP) and OTLP Receiver instead.
Deprecations:
* The `otlp` name for the OTLP gRPC Exporter in the OpenTelemetry Collector custom resource (CR) is deprecated. Use the `otlp_grpc` name instead. The `otlp` name will be removed in a future release.
* The `otlphttp` name for the OTLP HTTP Exporter in the OpenTelemetry Collector custom resource (CR) is deprecated. Use the `otlp_http` name instead. The `otlphttp` name will be removed in a future release.
Technology Preview features:
* Nothing
Enhancements:
* The following components, available as a Technology Preview before this update, are fully supported from version 3.9:
* Target Allocator
* Prometheus Exporter
* Prometheus Remote Write Exporter
* Filter Processor
* Transform Processor
* Kubernetes Events Receiver
* This update introduces the Metric Start Time Processor. You can use it to add start times to cumulative metrics after the Prometheus Receiver and benefit as follows: Improve historical data analysis by adding start time data for cumulative values. Enable the back end to accurately calculate request rates per minute. Enable threshold-based alerts.
* This release upgrades the Red Hat Universal Base Image (UBI) to version 9.
* This update adds support for overriding the Operator configuration by using environment variables.
* This update adds support for Prometheus scrape classes in the Target Allocator component.
* This update changes the configuration of the Kafka Receiver and Kafka Exporter in the OpenTelemetry Collector. The top-level encoding field is now deprecated. With this update, you must set encoding per signal type under logs, metrics, and traces. Use the raw encoding for logs only, because setting it at the top level and applied to all signal types causes a startup failure. For examples, see "Kafka Receiver" and "Kafka Exporter" in the Red Hat build of OpenTelemetry documentation (docs.redhat.com/en/documentation/red_hat_build_of_opentelemetry/latest/html-single/configuring_the_collector/index).
Bug fixes:
* Before this update, the NGINX and Apache instrumentation init containers were created by cloning the main container's configuration. As a consequence, there were issues with cloned liveness and readiness probes. With this release, the NGINX and Apache instrumentation init containers are defined independently, rather than inheriting inappropriate probe settings from the main container. As a result, issues with cloned liveness and readiness probes no longer occur.
* Before this update, the ServiceMonitor for the Operator metrics was not created due to a bug. With this release, the ServiceMonitor for the Operator metrics is created. For more information, see https://issues.redhat.com/browse/TRACING-5919.
* CVE-2025-61726: Before this update, a flaw existed in the `net/url` package in the Go standard library. As a consequence, a denial-of-service HTTP request with a massive number of query parameters could cause the application to consume an excessive amount of memory and eventually become unresponsive. This release eliminates this flaw. For more information, see https://access.redhat.com/security/cve/cve-2025-61726.
Known issues:
* The filesystem scraper does not produce the `system.filesystem.inodes.usage` and `system.filesystem.usage` metrics in the Host Metrics Receiver after upgrading from Collector version 0.142.0 to 0.143.0 or later. No known workaround exists. For more information, see https://issues.redhat.com/browse/TRACING-5963.
CVE-2025-71234 is a high-severity vulnerability in the Linux kernel's rtl8xxxu Wi-Fi driver. The driver fails to set hw->sta_data_size, causing mac80211 to allocate insufficient memory for driver private station data. This leads to a slab-out-of-bounds write when rtl8xxxu_sta_add accesses driver-specific data. The issue was identified via KASAN on RISC-V hardware with an RTL8192EU adapter. The flaw is fixed by setting hw->sta_data_size properly during driver probe to ensure correct memory allocation.
The KRVTZ-NET IDS alerts from February 15, 2026, report ongoing reconnaissance activity targeting Fortinet FortiOS VPN devices via repeated GET requests to the /remote/logincheck endpoint. This activity is linked to CVE-2023-27997, a vulnerability that allows unauthenticated attackers to probe VPN login endpoints remotely. While no active exploits or ransomware campaigns are currently tied to these alerts, the scanning indicates attackers are gathering information for potential future exploitation. The immediate severity is low, but unpatched vulnerabilities could lead to unauthorized access or denial of service. Organizations, particularly in Europe where Fortinet VPNs are prevalent, should prioritize patching and hardening VPN infrastructure to mitigate risk.
A vulnerability in the Linux kernel's drm/imx/tve driver was fixed to address a probe device reference leak. The issue involved not properly dropping the reference to the DDC device during probe failures or driver unbind, which could lead to resource leaks. This flaw has been resolved in updated kernel versions. The vulnerability has a medium severity rating with a CVSS score of 5.5 and does not impact confidentiality or integrity but affects availability. A patch is available and should be applied to affected systems. The vendor advisory confirms the fix and recommends updating to the patched kernel versions.
A medium severity vulnerability (CVE-2025-71196) in the Linux kernel's stm32-usphyc PHY driver was fixed by correcting an off-by-one error in the probe() function. The issue involved an 'index' variable used to access an array, which could go out of bounds if equal to the array size. The vulnerability was addressed by changing a boundary check from '>' to '>=' to prevent out-of-bounds access. This flaw originated from trusting device tree data, which is unlikely to be incorrect but still posed a risk. The fix is included in updated Linux kernel packages for Ubuntu 20.04 LTS and 22.04 LTS releases. Users are advised to apply the official patches and reboot systems to ensure remediation. No known exploits are reported in the wild.
A double-free vulnerability was identified and fixed in the Linux kernel's spi-sprd-adi driver. The issue arises from improper handling of the spi_controller structure during error paths in the probe function, leading to a double free of memory. This flaw could potentially cause system instability or crashes. The vulnerability has a CVSS score of 7.8, indicating a high severity impact on confidentiality, integrity, and availability. A patch is available and included in updated Linux kernel versions. Users are advised to update to the fixed versions and reboot to apply the changes.
In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: fix device leak on probe failure Make sure to drop the reference taken when looking up the ICU device during probe also on probe failures (e.g. probe deferral).
A vulnerability in the Linux kernel's dmaengine bcm-sba-raid driver caused a device reference leak during the probe process. This issue was fixed by ensuring that the reference taken when looking up the mailbox device is properly dropped on probe failures and driver unbind.
A total of 87 individuals, mostly Venezuelan nationals, have been charged for their role in the ATM jackpotting scheme. The post US Charges 31 More Defendants in Massive ATM Hacking Probe appeared first on SecurityWeek .
In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---
A flaw was identified in Keycloak’s OpenID Connect Dynamic Client Registration feature when clients authenticate using private_key_jwt. The issue allows a client to specify an arbitrary jwks_uri, which Keycloak then retrieves without validating the destination. This enables attackers to coerce the Keycloak server into making HTTP requests to internal or restricted network resources. As a result, attackers can probe internal services and cloud metadata endpoints, creating an information disclosure and reconnaissance risk.
CVE-2025-71141 addresses a flaw in the Linux kernel's drm/tilcdc driver where certain cleanup functions are called unconditionally during probe failure, causing warnings and improper removal actions. The issue is fixed by revising the cleanup path to ensure these functions are only called when the device is successfully registered. This prevents warnings during probe deferral scenarios and improves driver stability.
A use-after-free vulnerability in the Linux kernel's iommu/mediatek driver was fixed. The issue occurs when the driver drops references to larb devices during probe deferral, potentially leading to use-after-free if a larb device is not yet bound to its driver. This flaw has been addressed by retaining references while the iommu driver is bound. The vulnerability affects specific linux-hwe-edge kernel versions and has a CVSS score of 7.8. A patch is available and should be applied.
