A vulnerability in the Linux kernel's drm/vc4 driver was fixed by properly draining the hangcheck timer and related work on V3D unbind. The flaw allowed timer callbacks to access freed memory due to the timer not being stopped before the device was unbound and freed.
A vulnerability in the Linux kernel Bluetooth driver btintel_pcie was fixed to correct a bounds check error in the TX descriptor handling. The function btintel_pcie_prepare_tx used an index that could exceed the valid range of the transmit queue arrays, potentially leading to out-of-bounds access. This issue was addressed by rejecting an index equal to the transmit queue count, which is one past the end of the arrays.
A Linux kernel vulnerability was fixed that prevented scheduling deferred kernel page table freeing during system boot. The issue caused kernel panics when using a boot-time function tracer with a filter, due to workqueue usage before initialization. The fix delays scheduling the freeing work until the system is fully booted.
CVE-2026-99092 is a vulnerability in the Linux kernel affecting the riscv architecture's handling of bpf-jit execmem addresses. The issue arises from incorrect assumptions about memory writability in the vmalloc area when CONFIG_STRICT_MODULE_RWX is disabled, causing BPF JIT compilation to fail. This bug affects kernel version 6.10 and similar configurations where strict module RWX enforcement is not enabled. The flaw has been fixed in specific commits addressing the patch_map() function to correctly handle executable memory mappings for BPF JIT code.
A vulnerability in the Linux kernel Bluetooth management (MGMT) subsystem caused pending commands flushed on power off to report an incorrect status. Specifically, commands pending when the Bluetooth adapter powers off were incorrectly answered with a success status (0x00) instead of the appropriate error status (e.g., Not Powered or Invalid Index). This could cause user-space components like bluetoothd to crash due to unexpected responses. The issue has been fixed in Linux kernel versions 6.6.160, 6.2, 6.11, 6.12, and related releases.
CVE-2026-99090 is a vulnerability in the Linux kernel's AMDGPU driver where vblank counter reads are not properly serialized against GPU resets. This can cause unsafe hardware access during GPU recovery, triggering kernel warnings and tainting the kernel. The issue is fixed by acquiring a semaphore before hardware access or returning a cached software count if reset is in progress.
A vulnerability in the Linux kernel's ASoC Samsung i2s driver causes an imbalance in runtime power management due to the op_clk clock not being enabled during device probe. This leads to a warning during boot related to clock disablement. The issue is fixed by enabling op_clk in the probe function and disabling it in the remove function.
A vulnerability in the Linux kernel's Open vSwitch component related to IPv6 address rewrite actions on IPv6 fragments has been fixed. The issue occurs because the transport header is not properly validated before being accessed, leading to uninitialized memory reads that trigger warnings under debug configurations. The fix involves early return in the checksum update function to avoid reading uninitialized transport header offsets for IPv6 fragments.
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.
XQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel's own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.
rhc is a client tool and daemon that connects the system to Red Hat hosted services enabling system and subscription management.
Security Fix(es):
* net/http: golang: golang: Denial of Service via crafted HTTP Range headers (CVE-2026-78667)
* crypto/tls: golang: crypto/tls: Denial of Service via multiple ECH outer extension references (CVE-2026-97031)
* net/http: net/http/internal/http2: golang.org/x/net/http2: net/http: Denial of Service via excessive HTTP/2 SETTINGS frames (CVE-2026-78669)
* crypto/x509: golang: crypto/x509: Man-in-the-middle attacks via untrusted intermediate certificates (CVE-2026-111943)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
The boneIO Black web interface lacks proper clickjacking protections. A remote attacker can embed the control panel in an iframe on a malicious web page and trick an authenticated user on the internal network into clicking buttons that activate relays, open gates, or control blinds. This can lead to unauthorized state changes with potential physical safety consequences. Critically, due to CVE-2026-77053 (authentication disabled by default), any user on the same internal network can trigger attacker-controlled actions by visiting the malicious website.
This issue was fixed in version 1.6.0.
Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.
This issue affects Apache Camel: from 4.19.0 before 4.22.2.
OAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile's scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token's audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile’s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.
boneIO Black directly excludes several API endpoints from the authentication. An unauthenticated remote attacker on the local network can retrieve system logs, firmware version, serial number, MQTT username, configuration file listings, and API documentation. This data aids reconnaissance and enables targeted attacks against the device.
This issue was fixed in version 1.6.0: every API route requires an authenticated role, the interactive API documentation is disabled, and the serial number is withheld from anonymous callers.
boneIO black_debian_images stores the Mosquitto MQTT broker password file at /etc/mosquitto/passwd with world-readable permissions. Any local user can read the password hashes for all MQTT accounts and perform offline dictionary attacks.
This issue was fixed in version 1.6.0.
boneIO Black contains a TOCTOU race condition in the create_timedatectl_sudoers_file() function in boneio/webui/routes/timezone_sudoers.py. The function writes sudoers rules to a predictable temporary file, validates them, then installs them with root privileges. A local attacker can exploit the race window between validation and installation to substitute malicious content, or use the predictable filename for symlink attacks, resulting in arbitrary sudoers rule injection and local privilege escalation to root.
This issue was fixed in version 1.6.0.
boneIO Black is vulnerable to Cross-Site Request Forgery (CSRF) on all state-changing API endpoints because it lacks CSRF tokens and does not validate Origin or Referer headers. A remote attacker can craft a malicious webpage that, when visited by a user on the internal network, sends cross-origin requests to the device. This allows the attacker to reboot the controller, toggle relay circuits, control gates and blinds, or shut down the device, causing loss of integrity and availability. Critically, due to CVE-2026-77053 (authentication disabled by default), any user on the same internal network can trigger attacker-controlled actions by visiting the malicious website.
This issue was fixed in version 1.6.0.
boneIO Black versions prior to 1.6.0 do not limit authentication attempts on their web interface or SSH service and lack password complexity enforcement. This allows unauthenticated remote attackers to perform unlimited brute-force login attempts, potentially compromising user accounts and gaining unauthorized access. Version 1.6.0 addresses these issues by implementing rate limiting on web login attempts, enforcing a minimum password length of 8 characters, and restricting SSH authentication attempts to three per connection with a shortened login grace time.
Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server.
Security Fix(es):
* crypto/x509: golang: crypto/x509: Man-in-the-middle attacks via untrusted intermediate certificates (CVE-2026-111943)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
boneIO black_debian_images ships with a Mosquitto MQTT broker that uses the same default credentials on all devices. These credentials are publicly documented on github, and there is no indication in the instructions to change them. A remote attacker can use them to gain full read and write access to the broker, allowing control of connected relays, blinds, and gates, and injection of fake entities into a linked Home Assistant installation.
This issue was fixed in version 1.6.0 of the image: MQTT passwords are generated per device at first boot. Devices upgraded from earlier versions keep their existing broker credentials; from boneio 1.6.0 the web panel reports credentials that are still the published defaults, and the owner has to change them.
CVE-2026-77055 is a critical vulnerability in boneIO black_debian_images where the boneio service account is granted excessive privileges, including passwordless sudo access and membership in the docker group. This allows a local attacker who compromises the boneio user to escalate privileges to root. The issue is fixed in version 1.6.0 by removing these privileges and enforcing command restrictions with cryptographic verification.