CVE-2024-42154

What it actually does

Missing length validation on TCP_METRICS_ATTR_SADDR_IPV4 (and lack of policy enforcement for the attribute) allows a netlink message to supply a source address shorter than 4 bytes, resulting in out-of-bounds memory access when the kernel later dereferences or copies the attribute value.

Why it matters to the business

Unpatched Linux kernels on servers, routers, and appliances remain exposed to remote crashes or potential code execution, risking service outages, data exposure, and compliance violations until systems are updated.

How an attack unfolds

An attacker crafts a malicious netlink message containing a TCP_METRICS_ATTR_SADDR_IPV4 attribute whose length is deliberately set below four bytes and sends it to the kernel's generic netlink interface; the kernel accepts the message without validation, later reads or writes beyond the supplied buffer, and an attacker-controlled or adjacent data structure is corrupted.

How to fix it

Upgrade the Linux kernel to the commit 19d997b59fa1fd7a02e770ee0881c0652b9c32c9 or any later stable release that includes the validation fix; rebuild and reboot all affected systems; apply vendor-supplied updates as soon as they become available.

How to confirm the fix worked

Confirm the running kernel contains commit 19d997b59fa1fd7a02e770ee0881c0652b9c32c9 or newer; inspect the netlink policy definition for TCP_METRICS_ATTR_SADDR_IPV4 to verify a minimum length of four bytes is now enforced; run regression tests that attempt to send undersized saddr attributes and verify they are rejected.

Typical attack path

1. Identify a Linux system exposing the generic netlink interface reachable over the network or locally.
2. Construct a netlink message with TCP_METRICS_ATTR_SADDR_IPV4 set to a length of 0-3 bytes.
3. Transmit the message via the NETLINK_GENERIC socket.
4. Trigger kernel code paths that dereference the unvalidated attribute, causing memory corruption or information disclosure.
5. Escalate to denial of service or remote code execution depending on the resulting memory state.

How to detect it

Review netlink audit logs and kernel messages for malformed TCP metrics attribute submissions; search system logs for oops or panic entries referencing tcp_metrics or netlink attribute handling around the time of suspected activity.

What your security team should do

• Prioritize kernel updates on all internet-facing and high-value Linux systems within the next patching cycle.
• Monitor vendor advisories for backported fixes in distribution kernels.
• Temporarily restrict unprivileged netlink access where feasible until patches are deployed.
• Include the fixed commit hash in internal SBOM and vulnerability tracking systems.