CVE-2024-27417

What it actually does

Missing decrement of struct net reference count in inet6_rtm_getaddr when userspace supplies IFA_TARGET_NETNSID but omits both IFA_ADDRESS and IFA_LOCAL attributes, causing the function to return -EINVAL while leaving the reference elevated.

Why it matters to the business

Repeated triggering can exhaust kernel memory resources on affected Linux systems, leading to degraded performance or denial of service; the issue appears in widely used Red Hat systemtap packages and upstream kernels with thousands of downstream dependents.

How an attack unfolds

A local attacker crafts an RTNETLINK message containing a valid IFA_TARGET_NETNSID attribute but lacking address attributes, invokes inet6_rtm_getaddr, receives the error path that leaks the reference, and repeats the operation to accumulate unreleased struct net objects.

How to fix it

Upgrade affected packages to the listed fixed versions: systemtap, systemtap-client, systemtap-debuginfo, systemtap-grapher, systemtap-initscript, systemtap-runtime, systemtap-sdt-devel, systemtap-server and systemtap-testsuite to 0:1.4-6.el6_1.1 on Red Hat Enterprise Linux 6, or apply upstream kernel commit 9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132.

How to confirm the fix worked

Confirm installed package versions match the fixed releases, then exercise inet6_rtm_getaddr with a valid target netnsid and missing address attributes while monitoring reference counts or kernel memory usage.

Typical attack path

1. Obtain local unprivileged access on an affected Linux system
2. Construct a netlink message with IFA_TARGET_NETNSID but without IFA_ADDRESS or IFA_LOCAL
3. Send the message via the appropriate socket to trigger inet6_rtm_getaddr
4. Repeat the request to accumulate leaked struct net references

How to detect it

Inspect kernel logs and netlink audit records for repeated inet6_rtm_getaddr calls returning -EINVAL accompanied by elevated struct net reference counts; correlate with process activity invoking rtnetlink sockets.

What your security team should do

• Apply the listed package and kernel updates within the next maintenance window
• Prioritize systems exposing netlink interfaces to untrusted local users
• Review netlink usage in custom monitoring or orchestration tooling
• Track EPSS and KEV status for any future changes in exploit availability