A buffer overflow vulnerability in the Linux kernel's dm-integrity inline mode with large tag sizes has been fixed. The issue occurs because the checksum computation uses an on-stack buffer smaller than the tag size, causing an overflow when the tag size exceeds the buffer size. This overflow can cause kernel panics with stack protection enabled. The vulnerability requires root privileges to trigger and is not considered a security bug. Fixes have been applied in recent kernel commits.
A vulnerability in the Linux kernel's tee subsystem allows zero-sized allocations in tee_dyn_shm_alloc_helper(), leading to a kernel allocation failure and potential boot panic on systems with panic_on_warn enabled. This occurs because the function does not check for zero size before calling alloc_pages_exact(), which results in an invalid page order. The issue is triggered via TEE_IOC_SHM_ALLOC with a zero size parameter and has been fixed in specific commits.
A vulnerability in the Linux kernel's io_uring subsystem allowed disabled rings to bypass task restrictions on register operations until enabled. This could let a task with restricted register opcodes create a disabled ring, perform any register opcode on it, and then enable the ring without proper permission. The issue has been fixed by ensuring that rings inheriting restrictions from tasks are checked even while disabled, requiring explicit permission to enable them.
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.
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 versions from 1.2.0 up to but not including 1.6.0 are vulnerable to Cross-Site Request Forgery (CSRF) attacks on all state-changing API endpoints. The product lacks CSRF tokens and does not validate Origin or Referer headers, allowing remote attackers to craft malicious webpages that can perform unauthorized actions such as rebooting the controller, toggling relay circuits, controlling gates and blinds, or shutting down the device. This vulnerability leads to loss of integrity and availability. The issue is compounded by CVE-2026-77053, which disables authentication by default, enabling any user on the same internal network to trigger these actions. The vulnerability 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.
The boneIO black_debian_images product included a Mosquitto MQTT broker configured with default credentials that are identical across all devices and publicly documented. This allows remote attackers to gain full read and write access to the broker, enabling control over connected devices such as relays, blinds, and gates, and the injection of fake entities into linked Home Assistant installations. The vulnerability was fixed in version 1.6.0 by generating unique MQTT passwords per device at first boot. Devices upgraded from earlier versions retain their old credentials, but the web panel notifies owners if default credentials are still in use, prompting a change.