CVE-2023-53684

What it actually does

Uninitialized padding bytes in xfrm algorithm and encap structures containing kernel memory are copied to user-space during netlink dumps instead of being zeroed.

Why it matters to the business

Local processes may obtain fragments of kernel memory that could include sensitive internal state or cryptographic material, increasing risk of further attacks on systems running the affected kernel.

How an attack unfolds

A local attacker with access to the xfrm netlink interface requests dumps of algorithms or encapsulation templates; the kernel returns structures whose padding fields retain prior random or sensitive contents that the attacker then inspects.

How to fix it

Upgrade the Linux kernel to a version containing commit 0725daaa9a879388ed312110f62dbd5ea2d75f8f which zeros padding before copying xfrm structures to user-space.

How to confirm the fix worked

Confirm the presence of the zeroing patch in the xfrm_user.c source or verify the running kernel is newer than the listed fixed commit; test by exercising xfrm dump operations and inspecting returned structures for cleared padding.

Typical attack path

1. Obtain local shell or process execution as a non-root user
2. Open a netlink socket to the xfrm subsystem
3. Issue XFRM_MSG_GETALGO or XFRM_MSG_GETENCAP requests
4. Parse the returned nlmsghdr payloads for non-zero padding bytes

How to detect it

Audit netlink activity for repeated XFRM_MSG_GETALGO or XFRM_MSG_GETENCAP calls from non-privileged processes and inspect user-space buffers for anomalous non-zero padding after such calls.

What your security team should do

• Prioritize kernel upgrades on all systems exposing the xfrm netlink interface
• Apply the referenced commit or distribution backport within standard patch windows
• Review local user access controls to xfrm netlink sockets