CVE-2021-47131

What it actually does

Use-after-free of the TLS context after a netdev with active TLS offload is taken down and later brought up, leaving the socket referencing deallocated memory; subsequent data flow after TCP retransmissions triggers the freed object access on both TX (via fallback) and RX paths.

Why it matters to the business

Kernel memory corruption or crashes on systems using TLS hardware offload can cause network service outages, potential remote code execution, and require urgent patching of affected kernels and dependent packages across large fleets.

How an attack unfolds

An attacker with the ability to influence network device state or observe active TLS-offloaded connections forces a netdev down/up cycle while the socket remains open; after retransmissions resume traffic, the kernel dereferences the freed TLS context, enabling memory corruption that threat actors have targeted in Android kernel scenarios.

How to fix it

Upgrade the Linux kernel to a version containing the fix and update affected packages to the listed fixed versions (libblockdev-*-devel 2.24-2.el8_3 on AlmaLinux 8); disable TLS offload where feasible until patched; apply fallbacks to software kTLS.

How to confirm the fix worked

Confirm kernel and libblockdev package versions match or exceed the fixed releases; verify TLS offload is disabled or falls back cleanly on netdev restart; test connection resumption after simulated down/up cycles without crashes.

Typical attack path

1. Identify hosts with TLS offload enabled on network interfaces
2. Trigger or wait for netdev down event while TLS connections are active
3. Allow netdev to come back up and connections to resume after retransmissions
4. Trigger data flow that exercises the stale TLS context pointer
5. Exploit resulting use-after-free for memory corruption or code execution

How to detect it

Search kernel logs and netdev event logs for TLS context teardown messages followed by unexpected resync or fallback activity; look for crashes or warnings referencing tls_device_down or TLS_RX_DEV_DEGRADED around active TLS sockets.

What your security team should do

• Prioritize kernel and libblockdev updates on all systems exposing TLS offload within the next patching cycle due to the 935-day exposure window
• Audit network configurations for hardware TLS offload usage and consider disabling it on unpatched hosts
• Monitor for netdev state changes correlated with TLS connection anomalies in system logs