- CVE: CVE-2024-27018
Component: Linux Kernel br_netfilter
- Bug: Conntrack input hook is wrongly triggered for promiscuous bridge packets, leading to kernel warnings and potential state confusion.
- Exploitability: Not directly exploitable for RCE or privilege escalation out of the box, but may allow attackers on a bridged segment to trigger DoS and flooding of kernel log warnings, affecting system observability and conntrack correctness in complex setups.
Introduction
The Linux kernel is widely used in servers, desktops, and embedded devices, providing networking features such as bridging and “promiscuous” mode for packet sniffing and multi-tenant cloud environments.
br_netfilter is a module that provides bridge netfiltering (for features like iptables/nftables on bridge devices). However, a quirky scenario was found: with a bridge in promiscuous mode, certain packets leak into the connection tracking (conntrack) input hook when they should not—triggering warnings like those shown below, affecting system reliability and potentially security policy enforcement.
This article breaks down CVE-2024-27018 in plain language, shows what went wrong under the hood, and how it might be reproduced or abused.
What is br_netfilter and Promiscuous Mode?
- br_netfilter allows Linux bridges to filter (“see”) network traffic at L3 (IP layer), which helps manage IP tables NAT/masquerade state, often for containers/VMs.
- Promiscuous mode lets a bridge or NIC accept all packets, not just those addressed to it, typically for sniffers or VM setups with virtual tap devices.
Where's the Bug?
When a bridge enters promiscuous mode, traffic *cloned* for tap devices (not really “for” the bridge itself) can get passed up into the input processing path. The code failed to distinguish these “tapped” packets—so they got processed by the netfilter “input” hook *and* entered conntrack, which assumes each packet is unique to a flow. This double-handling confuses kernel state and, in tests, triggers kernel warnings (“splats”).
Example Kernel Warning (shortened)
WARNING: CPU: 1 PID: at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+x157/x180 [br_netfilter]
...
Call Trace:
...
br_nf_local_in+x157/x180 [br_netfilter]
nf_hook_slow+x3d/xd
br_pass_frame_up+xfc/x150
...
Commit Fix
A fix was committed upstream:
Patch Snippet
/* In br_input.c or br_netfilter_hooks.c */
/* Mark packets delivered to taps to avoid conntrack confusion */
BR_INPUT_SKB_CB(skb)->tap_delivered = 1; // Uses one spare bit
...
/* In netfilter input hook */
if (BR_INPUT_SKB_CB(skb)->tap_delivered)
return NF_ACCEPT; // Don't conntrack, just deliver up.
Access to create a bridge in promiscuous mode
- Means to inject traffic (e.g., virtual machines/containers connected to the bridge)
`
4. Generate traffic on the bridge, e.g., run a flood ping, or have a container attach to veth1 and send/receive traffic.
You might see the splat shown in your logs, e.g.
[ 57.571874] WARNING: CPU: 1 PID: at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+x157/x180 [br_netfilter]
While this isn't an exploit for RCE or a classic privilege escalation, *it is* a potential denial of service/chaos lever: A malicious VM or container could flood the bridge with crafted packets, filling your logs and risking conntrack table confusion.
Links to Originals
- Upstream fix commit (torvalds/linux)
- NVD entry for CVE-2024-27018
- Kernel.org netfilter bridge documentation
Who is exposed?
- Systems using Linux bridges in promiscuous mode (esp. cloud networking, containers, virtual switches)
- Anyone using containers/VMs with bridge forwarding and br_netfilter (e.g. kube-proxy in iptables mode with certain CNI plugins)
Mitigation
- Upgrade to a kernel with the commit merged (post-6.8)
- If unavailable: avoid setting bridges in promiscuous mode unless needed, or disable br_netfilter if not strictly required
Conclusion
CVE-2024-27018 is a classic case where a harmless-looking Linux network setting has ripple effects on deeper, security-relevant subsystems. While not directly allowing code execution, it's a good reminder that log and conntrack “mess” can lead to real trouble—especially in multi-tenant, noisy cloud/network environments.
References
- CVE-2024-27018 at NVD
- Upstream Linux commit fixing the bug
- Netfilter/Bridge Integration docs (kernel.org)
Timeline
Published on: 05/01/2024 06:15:20 UTC
Last modified on: 06/04/2024 17:46:18 UTC