Search: 36.9-2

The npm package 'airkey-mfa-react' versions 36.1.1, 35.1.1, 29.1.1, and 20.0.1 contain malicious code that executes during installation. It runs scripts that collect system information and user identity details, then exfiltrates this data to external malicious domains. The package appears to be part of a dependency-confusion attack targeting internal package namespaces. Systems with this package installed should be considered fully compromised.

Improper authorization in the /tequilapi/config/user endpoint of Mysterium Node from v1.21.1-rc0 before v1.36.0 allows an unauthenticated attacker to arbitrarily overwrite the node's configuration and achieve a full node takeover via a crafted POST request.

String::Util versions before 1.36 for Perl are susceptible to a regular expression denial of service. The trim and rtrim functions stripped trailing whitespace with s/\s*$//u. Because \s* matches greedily and the $ anchor fails whenever a non-whitespace character follows the whitespace, the regex engine retries the match at each offset of a long whitespace run, producing quadratic backtracking. The fix replaces \s*$ with \s+$. Any caller that passes untrusted input to trim or rtrim can trigger CPU exhaustion with a string containing a long run of whitespace.

The npm package @athena-ui-components/user-activity versions 1.9.35 and 1.9.36 contain malicious code. This issue has been identified as a malicious package threat but lacks detailed technical or impact information. No official patch or remediation guidance is currently provided.

This update for c-ares fixes the following issues: Updat to c-ares 1.36.8. - CVE-2026-33630: remotely triggerable use-after-free/double-free in query-completion handling via `ares_getaddrinfo()` over TCP (bsc#1270416). - CVE-2026-69184: CPU exhaustion denial of service via unbounded DNS name compression pointer chains (bsc#1276290). - CVE-2026-69186: memory amplification denial of service via unvalidated DNS header record counts (bsc#1276291). Changes for c-ares: - For details, see https://c-ares.org/changelog.html.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (4ae0aa9efa2a8389cfe9d5c41d5ab3689f4965c945a24613493f94f9de033ab1) schemavault 4.1.0 is presented as a schema-validation library but ships capabilities and data that have no relationship to schema validation. schemavault/_registry.py defines three underscore-prefixed byte arrays: `_ep` (36 bytes), `_p` (7 bytes), and `_k` (16 hex constants shaped like a symmetric key). None of these names are read anywhere in the schemavault package. schemavault/imaging.py exports `extract_metadata()`, an LSB steganography decoder that reads a length-prefixed hidden string from the shipped asset `schemavault/assets/logo.bmp` (first 16 bits = length, then length*8 bits of pixel-LSB characters); this function is likewise not invoked from anywhere in schemavault. setup.py declares `install_requires=['bytekit']` — an unpinned, generically named dependency unrelated to schema validation. The pattern is a two-package split: the primary package holds encoded payload material and a decoder utility, and the unpinned generically-named dependency is positioned to be the loader that actually decodes and executes the staged content on install or import. Because pip resolves `bytekit` without a version pin from whichever registry is configured, `pip install schemavault` pulls attacker-controlled code into the installer's environment. The dormant carrier data + LSB decoder + unrelated unpinned loader dep together match the staged-dropper shape rather than any legitimate schema-library composition. ## Source: kam193 (2af83487d12e2c9e16e3a5fae1ac369bacd5d39622a04c537edd0dbdda4a143a) The campaign consists of multiple packages. The trigger sits in the package 'procwire,' which depends on two others. During installation, procwire uses schemavault and bytekit packages. The first one holds the URL holding malware (in two places, once as steganography in the bundled image and once as a fallback just as a list of encoded bytes). The bytekit implements simple custom decoding used to retrieve back the URL in the fallback method. Additionally, procwire is also a dependency of confighub, turning another package into malware. The downloaded executable is run and quickly removed. The executable likely contains an infostealer and contacts the domain 030502[.]xyz --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-procwire Reasons (based on the campaign): - The package overrides the install command in setup.py to execute malicious code during installation. - Downloads and executes a remote executable. - obfuscation - The malicious code is intentionally included in a dependency of the package - malware - steganography

CISA’s BOD 26-04 changes how federal agencies patch and how security leaders must measure, justify, and communicate cyber risk to executives and boards. Key takeaways BOD 26-04 requires agencies to make and defend risk-based vulnerability prioritization decisions, including decisions to defer vulnerability remediation. This accountability requirement transforms vulnerability management from a technical operation into a governance discipline that demands audit-ready documentation. Traditional vulnerability management KPIs (total vulnerabilities patched, mean time to patch, percentage of systems scanned) do not measure what BOD 26-04 demands. The metrics that matter are coverage breadth and risk-tier remediation rates. Tenable’s analysis of customer telemetry shows that monitoring coverage breadth is a stronger predictor of risk posture than patch speed, a finding independently corroborated by research showing organizations can remediate only about 10% of open vulnerabilities per month regardless of size or maturity. The directive’s reach extends beyond federal agencies to thousands of federal contractors who must align with BOD 26-04 through contract compliance requirements. Organizations in the federal supply chain should treat the directive as an operational requirement, not advisory guidance. The shift from patching metrics to risk exposure metrics is not a federal-only phenomenon. Industry reporting standards, insurance underwriting models, and board-level accountability expectations are converging on the same demand: prove that you are reducing actual risk, not just closing tickets. The reporting mandate hiding inside CISA Binding Operational Directive (BOD) 26-04 Most coverage of CISA BOD 26-04 has focused on the operational requirements: the four-variable model, the 16-tier remediation matrix, the three-day BOD 26-04 patching timeline with mandatory forensic triage. These are significant, and Tenable has covered them in depth in our FAQ on BOD 26-04 . But buried in the directive’s requirements is a less-discussed obligation that may prove equally transformative: agencies must demonstrate how they prioritize vulnerabilities and justify their decisions, particularly in cases where they decide to defer remediation. Metrics are expected to evolve from simple counts of patched vulnerabilities to measures that reflect reduction in high-risk exposure. This is not a minor procedural update. It is a fundamental shift in how cybersecurity programs are measured, reported, and held accountable. For CISOs and security leaders, BOD 26-04 doesn’t just change the patching workflow. While the BOD 26-04 directive formally targets federal agencies, its framework is rapidly becoming the blueprint for the private sector as market forces align around risk-based accountability. Ultimately, it changes what corporate boards of directors need to hear. Why traditional vulnerability management metrics fail under BOD 26-04 For years, security leaders have measured vulnerability management programs by volume: Total vulnerabilities identified Total patches applied Percentage of systems scanned within a 30-day window Mean time to remediate. These metrics are easy to collect, easy to report, and easy to trend over time, but they are also increasingly disconnected from actual risk. Tenable’s own analysis of customer telemetry across our global customer base confirms what many security leaders suspect but cannot prove: breadth of monitoring coverage is a more robust, predictive risk signal than patch velocity. Unmonitored assets exist as a permanently open attack surface; they cannot generate findings, be prioritized, or be verified as remediated. Conversely, monitored assets still pass through the risk pipeline even if remediation isn’t operating at maximum speed. Independent industry research heavily corroborates the need to shift reporting from patching speed to monitoring coverage: The remediation ceiling - The Cyentia Institute’s Prioritization to Prediction research (analyzing 3.6 billion vulnerability observations) found that the typical organization can only remediate roughly 10% of open vulnerabilities per month, regardless of size, industry, or maturity. Because you cannot out-patch the growth rate of your backlog, prioritization, not speed, is the only lever that meaningfully reduces risk. The MTTR flaw - Standard mean-time-to-remediate (MTTR) calculations exclude open, unremediated vulnerabilities, which skews your metrics toward items that are easier to close quickly, which may not be the most critical, severe, or highest-risk issues. Asset composition skew - Remediation half-lives vary wildly across asset types, averaging 36 days for Microsoft Windows systems versus 369 days for network appliances. A strong MTTR often just means you have good visibility into automatically patching Windows assets, but this KPI may hide persistent exposure on edge devices and OT systems. BOD 26-04 makes this explicit: remediation priority is determined by the risk posed by a vulnerability if exploited, not by the total number of vulnerabilities identified. The directive’s deferral tier (fix on system upgrade) formalizes what the data has always shown: most vulnerabilities can wait. The ones that cannot are defined by exploitation evidence, exposure, automation potential, and impact severity. A CISO who reports, “We patched 95% of critical CVEs this quarter,” is reporting a metric that BOD 26-04 has rendered insufficient. The relevant question is: Of the vulnerabilities that posed real-world risk to mission-critical systems, what percentage did we remediate within the directive’s timeline, and how much of our attack surface was under observation when we made that assessment? The new security metrics: What BOD 26-04 demands The shift from volume-based to risk-based reporting requires new KPIs. Organizations implementing BOD 26-04 should consider metrics that reflect the directive’s four-variable prioritization model: Remediation compliance by BOD tier. What percentage of vulnerabilities in each BOD tier (three-day forensic triage, three-day, 14-day, 60-day, system upgrade) are remediated within the applicable timeline? This is the core compliance metric. It replaces “mean time to remediate” with a risk-weighted measurement that distinguishes between a 3-day critical and a deferrable low-risk finding. Coverage of actively exploited vulnerabilities. What percentage of KEV -listed vulnerabilities in the environment are remediated? This measures the response to the most dangerous known threats, not the total vulnerability population. Exposure surface reduction over time. What is the trend in assets classified as publicly exposed (BOD Variable 1)? Reducing the number of internet-facing assets directly shifts vulnerabilities from compressed timelines to the deferral tier. Tenable’s analysis of the full CISA Vulnrichment corpus found that removing an asset from public exposure can shift 76.7% of its associated CVEs to longer remediation windows. This makes exposure reduction the single highest-leverage compliance investment. Additional independent research reinforces why assessment coverage is a better indicator of risk outcomes than patch velocity. Joint analysis from XM Cyber and the Cyentia Institute, examining more than 60 million exposures across 10 million entities, found that 75% of security exposures do not put critical assets at risk: they are dead ends in the attack graph. Only 2% of exposures sit on “choke points,” the convergence nodes through which multiple attack paths transit en route to critical assets. This corroborates Tenable’s telemetry finding from a different angle: if your monitoring does not cover the entities where those choke points exist, your remediation speed on the other 98% is noise in the risk signal. The metric that matters is not how fast you patch, but whether your visibility extends to the places where attack paths converge. Forensic triage completion rate. For vulnerabilities in the highest-risk tier (KEV + total control), what percentage received the required BOD 26-04 forensic triage guidelines within the three-day window? This measures compliance with the directive’s most novel and operationally demanding requirement. Deferral justification documentation rate. For vulnerabilities placed in the “fix on system upgrade” tier, what percentage have documented risk acceptance decisions? BOD 26-04 requires agencies to justify deferral decisions, which means every deferred vulnerability needs an auditable rationale. Mean time from KEV addition to remediation. How quickly does the organization respond when a CVE is added to the KEV catalog and its BOD timeline compresses? This measures the speed of the organization’s response to dynamic timeline changes. These metrics share a common characteristic: they measure risk reduction outcomes, not activity volume. A security program that patches fewer total vulnerabilities but remediates 100% of the 3-day tier within three days is performing better under BOD 26-04 than one that patches twice as many total CVEs but misses the critical timelines. The accountability requirement: Justifying decisions to defer vulnerability remediation BOD 26-04 introduces something federal vulnerability management has never had: a formal requirement to justify prioritization decisions. When an agency defers remediating a vulnerability to the next system upgrade cycle, that decision must be documented and defensible. This creates an audit trail requirement. For every deferred vulnerability, the organization needs to demonstrate: Which of the four variables were assessed What combination placed the vulnerability in the deferral tier Why the agency is confident the deferral does not create unacceptable risk If any of the four variables change (a CVE added to the KEV, an asset newly exposed to the internet), the deferral decision must be reassessed. For CISOs, this means the vulnerability management pro

Missing Critical Step in Authentication vulnerability in Apache Tomcat when the JNDIRealm was configured to authenticate binds using GSSAPI allowed attackers to authenticate without provided the correct password. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.4, from 10.1.0-M1 through 10.1.36, from 9.0.0.M1 through 9.0.100, from 8.5.0 through 8.5.100, from 7.0.0 through 7.0.109. Users are recommended to upgrade to version 11.0.5, 10.1.37 or 9.0.101, which fixes the issue.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (aa2ddbcbdd90508af14415a021644c1ab8a57e432b526425e4c5128b23f897bb) endpointmap advertises itself as a REST endpoint registry but exhibits a two-package smuggle pattern. lib/registry.js exports two non-printable byte arrays (`_ep` of length 36, `_p` of length 7) annotated as 'Endpoint host segment' / 'Endpoint path segment', with a comment claiming they are 'processed at runtime by the consumer for portability.' Neither array is read anywhere in endpointmap's own code — index.js only exposes the registry object — and the bytes are opaque (XOR-shaped, with no key shipped in this package). At the same time, package.json declares `"bytecraft": "*"` as a dependency. endpointmap's source never `require`s bytecraft; the only effect of the declaration is to force installation of whatever `bytecraft@latest` happens to be at install time. The combination — staged encoded data in this package plus an unpinned, never-imported sibling that can be updated to act as the decoder/runtime — is the canonical 'data here, decoder there' split designed to evade per-package review. An installer of endpointmap is exposed to whatever bytecraft resolves to at install/require time, including future malicious versions, without endpointmap itself ever needing another release. ## Source: ghsa-malware (7cf1ae7dc26d8ebda1199b5e88d8fb0d49e4db8f72ff01b5f2b0dea88cf4a8a0) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.36.0 until 1.36.9, 1.37.5, and 1.38.3, a Use-After-Free (UAF) vulnerability leading to a sudden segmentation fault exists in Envoy's ext_authz HTTP filter when processing per-route authorization overrides concurrently with rapid downstream client disconnects. During standard request lifecycles, Envoy instantiates the ext_authz filter with a foundational authorization client object (client_). If a matched route dictates a dynamic per-route HTTP or gRPC authorization service override, the filter generates a localized client. In the vulnerable implementation, this transient client aggressively overwrote the default client_ unique pointer by executing client_ = std::move(per_route_client). When a client rapidly establishes and subsequently tears down a stream (such as rapidly refreshing a protected WebSocket endpoint), the downstream triggers the ConnectionManagerImpl::doDeferredStreamDestroy() -> ActiveStream::onResetStream() lifecycle. Envoy immediately sequences Filter::onDestroy() in an attempt to securely abort dispatched asynchronous authorization check transactions via client_->cancel(). By destructing the default client abruptly during initiateCall, a memory lifecycle misalignment occurs within the async client manager. The stream teardown fails to reliably track and cancel the dynamically bound asynchronous authorization tasks, orchestrating a sequence where a late asynchronous callback from the network evaluates against a heavily destroyed ActiveStream validation span, generating a UAF process crash. This vulnerability is fixed in 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, PROXY Protocol v2 header generator emits TLVs beyond the maximum length of 65535 bytes, causing a mismatch between bytes written and the length field in the header. This can result in smuggled bytes on the upstream request. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, Envoy crashes if an ext_proc server sends a single gRPC message containing multiple, specially crafted ProcessingResponse messages. This can occur when the first response in the batch causes the gRPC stream object to be destroyed, leading to a use-after-free error when Envoy attempts to process subsequent responses in the same gRPC message. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, a vulnerability exists in Envoy's TCP StatsD sink (TcpStatsdSink), where the thread-local flusher buffer can be overflowed by exceptionally long statistic names (e.g., >16KiB). During formatting, TcpStatsdSink reserves a single contiguous memory slice of 16KiB (FLUSH_SLICE_SIZE_BYTES). If formatting a single metric exceeds the remaining capacity, the flusher initiates a buffer rotation but incorrectly continues to allocate another fixed 16KiB slice. If an attacker can trigger a statistic name longer than 16KiB—for example, by sending an HTTP or gRPC request with an extremely long request path (:path) that is recorded by the grpc_stats filter configured with stats_for_all_methods: true—the flusher will attempt to copy the metric name using memcpy operations beyond the allocated heap buffer boundaries. This leads to a heap write overflow, which can cause immediate denial-of-service (process crash) or potential remote code execution (RCE). This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.26.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, the envoy.filters.http.grpc_stats filter crashes (null pointer dereference / segfault) when a Connect protocol request (Content-Type: application/connect+proto or application/connect+json) hits a direct_response route. A single unauthenticated HTTP request crashes the Envoy process. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.18.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, the router filter contains a null pointer dereference vulnerability when handling HTTP 303 (See Other) internal redirects for body-less non-GET/HEAD requests. When a POST, PUT, DELETE, or PATCH request without a body is sent to a route configured with internal redirect policy that includes 303 in redirect_response_codes, and the upstream responds with HTTP 303, the redirect handling code attempts to drain a request body buffer that was never allocated. This results in a segmentation fault that crashes the entire Envoy process. When route configured with internal_redirect_policy including 303 in redirect_response_codes and upstream must return HTTP 303 response, an unauthenticated attacker can exploit this to cause complete denial of service, terminating all active connections. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.35.11, 1.36.7, 1.37.3, and 1.38.1, in cases where UDP DNS filter is configured with local resolution containing a name with the length of 255 octets or remote resolution for a name of 255 octets long can complete successfully, a query with such name will result in abnormal process termination. The abnormal process termination is triggered by an invalid runtime precondition that the query name is strictly less than 255 octets, contradicting DNS specification rfc1035#section-2.3.4 that the name can be 255 or less octets. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.23.0 until 1.35.11, 1.36.7, 1.37.3, and 1.38.1, a vulnerability has been identified in Envoy's zstd decompressor implementation (ZstdDecompressorImpl). When zstd decompression is enabled, processing a specially crafted, highly compressed zstd payload can lead to massive memory allocation. An attacker can exploit this to cause severe memory exhaustion, potentially resulting in an Out-Of-Memory (OOM) kill and Denial of Service (DoS) for the Envoy proxy. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.35.11, 1.36.7, 1.37.3, and 1.38.1, the OAuth2 HTTP filter's encrypt()/decrypt() functions use AES-256-CBC without an authentication tag (no HMAC, no AEAD). The /callback endpoint returns HTTP 302 on successful decryption and HTTP 401 on padding failure, creating a padding oracle. An attacker who obtains the encrypted CodeVerifier cookie can recover the plaintext PKCE code_verifier in ~6,200 requests (~100 seconds), then exchange it with a stolen authorization code to obtain the victim's access token. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

In the Linux kernel, the following vulnerability has been resolved: bonding: 3ad: implement proper RCU rules for port->aggregator syzbot found a data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler [1] which hints at lack of proper RCU implementation. Add __rcu qualifier to port->aggregator, and add proper RCU API. [1] BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler write to 0xffff88813cf5c4b0 of 8 bytes by task 36 on cpu 0: ad_port_selection_logic drivers/net/bonding/bond_3ad.c:1659 [inline] bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c:2569 process_one_work kernel/workqueue.c:3302 [inline] process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3385 worker_thread+0x58a/0x780 kernel/workqueue.c:3466 kthread+0x22a/0x280 kernel/kthread.c:436 ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 read to 0xffff88813cf5c4b0 of 8 bytes by task 22063 on cpu 1: __bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c:2858 [inline] bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c:2881 bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c:853 rtnl_link_info_fill net/core/rtnetlink.c:906 [inline] rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c:927 rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c:2168 rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c:4453 rtmsg_ifinfo_event net/core/rtnetlink.c:4486 [inline] rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c:4495 __dev_notify_flags+0x76/0x390 net/core/dev.c:9790 netif_change_flags+0xac/0xd0 net/core/dev.c:9823 do_setlink+0x905/0x2950 net/core/rtnetlink.c:3180 rtnl_group_changelink net/core/rtnetlink.c:3813 [inline] __rtnl_newlink net/core/rtnetlink.c:3981 [inline] rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c:4109 rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c:6995 netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c:2550 rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:7022 netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline] netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c:1344 netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c:1894 sock_sendmsg_nosec net/socket.c:787 [inline] __sock_sendmsg net/socket.c:802 [inline] ____sys_sendmsg+0x563/0x5b0 net/socket.c:2698 ___sys_sendmsg+0x195/0x1e0 net/socket.c:2752 __sys_sendmsg net/socket.c:2784 [inline] __do_sys_sendmsg net/socket.c:2789 [inline] __se_sys_sendmsg net/socket.c:2787 [inline] __x64_sys_sendmsg+0xd4/0x160 net/socket.c:2787 x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f value changed: 0x0000000000000000 -> 0xffff88813cf5c400 Reported by Kernel Concurrency Sanitizer on: CPU: 1 UID: 0 PID: 22063 Comm: syz.0.31122 Tainted: G W syzkaller #0 PREEMPT(full) Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026