CVE-2024-27395

What it actually does

Use-after-free in ovs_ct_exit during RCU-protected hlist traversal of ovs_ct_limit entries because kfree_rcu occurs outside the RCU read critical section, allowing the grace period to expire and the key to be freed while still referenced.

Why it matters to the business

Local attackers with low privileges can achieve arbitrary code execution or kernel memory corruption on affected Linux systems, leading to full host compromise, data theft, or denial of service in environments using Open vSwitch with connection tracking limits.

How an attack unfolds

An attacker with local access crafts network traffic or configuration that triggers repeated addition and removal of ct_limit entries in Open vSwitch while concurrent RCU grace periods expire, causing the traversal to dereference a freed key and execute attacker-controlled code.

How to fix it

Update the Linux kernel to the commit 2db9a8c0a01fa1c762c1e61a13c212c492752994 or later stable releases that replace hlist_for_each_entry_rcu with hlist_for_each_entry_safe in ovs_ct_limit_exit; rebuild and reboot affected systems.

How to confirm the fix worked

Verify the running kernel source contains the safe traversal change in net/openvswitch/conntrack.c and confirm no vulnerable code path remains via code review or kernel version checks against the fixed commit.

Typical attack path

1. Obtain local user access on a Linux host running a vulnerable kernel with Open vSwitch and ct_limit enabled
2. Trigger repeated ct_limit operations via crafted netlink messages or network flows to race with RCU reclamation
3. Force the hlist traversal in ovs_ct_limit_exit to reference a kfree_rcu'd entry after the grace period
4. Leverage the resulting use-after-free for kernel memory corruption or code execution

How to detect it

Review kernel logs for oops or panic messages referencing ovs_ct_limit_exit or conntrack; inspect auditd and dmesg for unusual netlink activity involving Open vSwitch ct_limit operations around the time of any crash or unexpected behavior.

What your security team should do

• Prioritize patching all systems using Open vSwitch with connection tracking limits within standard maintenance windows
• Audit kernel configurations for ovs_ct_limit usage and restrict local user access where possible until updated
• Monitor upstream stable kernel releases for backports and apply them promptly given the local privilege-escalation impact