{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-27018", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-27018" ], "published": "2024-05-01T05:31:05Z", "summary": "netfilter: br_netfilter: skip conntrack input hook for promisc packets", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: br_netfilter: skip conntrack input hook for promisc packets\n\nFor historical reasons, when bridge device is in promisc mode, packets\nthat are directed to the taps follow bridge input hook path. This patch\nadds a workaround to reset conntrack for these packets.\n\nJianbo Liu reports warning splats in their test infrastructure where\ncloned packets reach the br_netfilter input hook to confirm the\nconntrack object.\n\nScratch one bit from BR_INPUT_SKB_CB to annotate that this packet has\nreached the input hook because it is passed up to the bridge device to\nreach the taps.\n\n[ 57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core\n[ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19\n[ 57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[ 57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1\n[ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202\n[ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000\n[ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000\n[ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003\n[ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000\n[ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800\n[ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000\n[ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0\n[ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[ 57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[ 57.585440] Call Trace:\n[ 57.585721] \n[ 57.585976] ? __warn+0x7d/0x130\n[ 57.586323] ? br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.586811] ? report_bug+0xf1/0x1c0\n[ 57.587177] ? handle_bug+0x3f/0x70\n[ 57.587539] ? exc_invalid_op+0x13/0x60\n[ 57.587929] ? asm_exc_invalid_op+0x16/0x20\n[ 57.588336] ? br_nf_local_in+0x157/0x180 [br_netfilter]\n[ 57.588825] nf_hook_slow+0x3d/0xd0\n[ 57.589188] ? br_handle_vlan+0x4b/0x110\n[ 57.589579] br_pass_frame_up+0xfc/0x150\n[ 57.589970] ? br_port_flags_change+0x40/0x40\n[ 57.590396] br_handle_frame_finish+0x346/0x5e0\n[ 57.590837] ? ipt_do_table+0x32e/0x430\n[ 57.591221] ? br_handle_local_finish+0x20/0x20\n[ 57.591656] br_nf_hook_thresh+0x4b/0xf0 [br_netfilter]\n[ 57.592286] ? br_handle_local_finish+0x20/0x20\n[ 57.592802] br_nf_pre_routing_finish+0x178/0x480 [br_netfilter]\n[ 57.593348] ? br_handle_local_finish+0x20/0x20\n[ 57.593782] ? nf_nat_ipv4_pre_routing+0x25/0x60 [nf_nat]\n[ 57.594279] br_nf_pre_routing+0x24c/0x550 [br_netfilter]\n[ 57.594780] ? br_nf_hook_thresh+0xf0/0xf0 [br_netfilter]\n[ 57.595280] br_handle_frame+0x1f3/0x3d0\n[ 57.595676] ? br_handle_local_finish+0x20/0x20\n[ 57.596118] ? br_handle_frame_finish+0x5e0/0x5e0\n[ 57.596566] __netif_receive_skb_core+0x25b/0xfc0\n[ 57.597017] ? __napi_build_skb+0x37/0x40\n[ 57.597418] __netif_receive_skb_list_core+0xfb/0x220", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.6.28-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.6.28+rpt-rpi-2712", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v6", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7l", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v8", "binary_version": "1:6.6.28-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.29" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-27018" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dceb683ab87ca3666a9bb5c0158528b646faedc4" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b13db0d16bc7b2a52abcf5cb71334f63faa5dbd6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3f59ac29dea0921637053908fe99268d157bbb9d" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/43193174510ea4f3ce09b796e559a2fd9f148615" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/751de2012eafa4d46d8081056761fa0e9cc8a178" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.2, "cvss_v3_severity": "High", "scenario": "AV:N - The defect is in the bridge receive path (net/bridge/br_input.c \u2192 br_nf_local_in), driven purely by received frames and their IP/L4 content, which determines the conntrack tuple; on a bridging VM/container host any remote sender's packets routed to a bridged guest arrive with pkt_type != PACKET_HOST and take this exact path. No authentication, session, or local access is needed \u2014 only the ability to get packets to a bridged endpoint.\nAC:L - Once the bridge device is in promiscuous mode (set automatically by macvlan/macvtap on top of br0, or by any tap/tcpdump \u2014 the reporter's own routine test setup), every frame crossing the bridge deterministically reaches br_pass_frame_up() and the conntrack confirm hook; the attacker wins no race and needs no special memory layout. br_netfilter + conntrack + bridging is the default configuration on Docker/Kubernetes/libvirt hosts, not a rare option.\nPR:N - The path runs in softirq context on packet receive with no capability, credential, or authentication check anywhere between the NIC and br_nf_local_in(). An unauthenticated sender is sufficient; the alternative local route via unprivileged user namespaces would only be PR:L, so None is the correct broader value.\nUI:N - Triggering requires only that the attacker transmit frames that traverse the bridge; no administrator or user on the target system needs to open, mount, or click anything.\nS:U - The faulty conntrack confirmation, the WARN, and any resulting state damage are all contained within the kernel's own network stack and its security authority. There is no crossing of a VM, IOMMU, or sandbox boundary.\nC:N - The bug confirms conntrack entries and emits warnings; no attacker-observable memory contents or kernel addresses are returned to the attacker. The stale conntrack pointer read on the clash path feeds only a WARN_ON_ONCE and never propagates data outward.\nI:L - Attacker traffic causes the host to create and confirm conntrack entries for flows it is not a party to, and confirmation at LOCAL_IN explicitly disables NAT and conntrack helpers for those flows (per commit 62e7151ae3eb), so a bridging firewall silently fails to apply its NAT/helper policy and its connection-tracking state is polluted with attacker-seeded entries. This is a bounded, security-relevant modification of kernel firewall state rather than arbitrary write capability.\nA:H - Remotely sent frames trigger kernel WARN splats in br_nf_local_in() and __nf_conntrack_confirm(), which is a kernel panic on the many hardened/cloud/CI kernels built with panic_on_warn=1. Even without that, the failed concurrent confirms return NF_DROP (packet loss on the bridge) and a promiscuous bridge under attacker traffic fills the conntrack table with entries for observed third-party flows, exhausting nf_conntrack_max and denying service to the host's own and forwarded traffic." } } }