CVE-2025-38210

What it actually does

Missing registration checks in tsm_report_privlevel_store() and tsm_report_provider_show() allow NULL dereference of tsm_ops after tsm_unregister() succeeds, classified as memory corruption.

Why it matters to the business

Kernel crashes on Linux systems exposing TSM attestation via configfs may interrupt workloads and require coordinated driver reloads; low urgency given absence from KEV and minimal EPSS trend despite noted similar privilege-escalation activity in the kernel ecosystem.

How an attack unfolds

An attacker with local access first triggers tsm_unregister via driver unbind, then performs store or show operations on lingering configfs items created by tsm_report_make_item; the absent checks allow the NULL pointer dereference to occur before safe failure paths are reached. Related Advanced Spyware Campaign and Linux kernel privilege-escalation activity targeting similar CVEs may seek analogous attestation-surface weaknesses.

How to fix it

Upgrade affected packages to the listed fixed versions: aws-flb-kinesis-fips and aws-flb-kinesis-compat-fips to 1.10.2-r12; Linux kernel trees to commit 015f04ac884a454d4d8aaa7b67758f047742b1cf. Coordinate deletion of open config-items before rebinding the driver after an emergency unregistration.

How to confirm the fix worked

Confirm the patch commit or package version is present; attempt tsm_unregister followed by attribute access on remaining config-items and verify that store/show operations now return safe errors instead of crashing.

Typical attack path

1. Obtain local access and locate TSM configfs hierarchy
2. Trigger tsm_unregister by unbinding the tsm_arch-guest driver
3. Access tsm_report_privlevel or provider attributes on existing items
4. Cause NULL dereference and kernel panic

How to detect it

Review kernel ring buffer and dmesg for NULL pointer dereference oops mentioning tsm_report_privlevel_store or tsm_report_provider_show after tsm_unregister; correlate with configfs item creation timestamps and driver unbind events.

What your security team should do

• Apply the fixed kernel commit or Chainguard package versions immediately on systems exposing TSM attestation
• Audit and remove lingering configfs items before any planned driver reload or unbind
• Monitor kernel logs for oops involving tsm_report functions
• Limit configfs write access to trusted processes only