Anyone else's Falcon sensor chewing CPU after the 6.45 update?

I've been observing a concerning pattern across a subset of our Kubernetes worker nodes since the deployment of the CrowdStrike Falcon sensor version 6.45. The sensor process (`falcon-sensor`) is exhibiting sustained high CPU utilization, often between 80-120% (as measured per core), where previously it was a negligible background process. This is not an ephemeral spike during a scan but a persistent state that triggers cluster autoscaler events and impacts application performance.

The environment where this is most pronounced:
* **Kubernetes:** EKS 1.27, Linux kernel 5.15
* **Deployment Method:** Falcon Container DaemonSet (per the CrowdStrike Helm chart)
* **Node Types:** `c6i.2xlarge` and `m5.2xlarge` instances
* **Workload:** Mixed, but nodes running Java (JVM) applications appear to be disproportionately affected.

Initial diagnostic steps have ruled out obvious culprits:
* The node's overall memory and I/O pressure are low.
* No corresponding increase in kernel thread activity (`syscall`, `iowait`).
* The pattern is inconsistent; approximately 30% of nodes on the same version show this behavior, while 70% do not, despite identical base AMIs and DaemonSet configuration.

Data gathered from `perf` sampling on an affected node points heavily to userspace processing within the sensor. A frequent stack trace excerpt:

```bash
# Children Self Command Shared Object Symbol
# 92.34% 85.12% falcon-sensor falcon-sensor [.] SymbolizedFunctionX
# |
# ---SymbolizedFunctionX
# |
# |--71.28%-- SomePatternMatchRoutine
# | |
# | |--65.44%-- __strlen_avx2
```

This suggests a possible regression in a string or pattern matching algorithm, perhaps related to the new "On-Sensor Machine Learning" features highlighted in the 6.45 release notes. The correlation with JVM nodes could be a red herring, or it might indicate that the sensor's inspection logic is interacting poorly with the specific memory access patterns or file descriptors of JVM processes.

I am seeking to gather more data points before engaging support. Specifically:

* Is anyone else observing similar CPU profiles post-6.45, particularly in containerized or Kubernetes environments?
* Have you identified any workarounds, such as adjusting the `sensorPolicy` CPU limit (which we have temporarily implemented, though it feels like masking the symptom)?
* Does the pattern correlate with specific kernel versions, or the presence of certain workload types (e.g., JVM, Go binaries)?

My next step is to perform a controlled rollback to 6.43 on a test node group to confirm the version correlation definitively. Any shared observations would be valuable in building a collective case.