Release Date: | 2024-05-17 |
In the Linux kernel, the following vulnerability has been resolved:\nnetfilter: bridge: confirm multicast packets before passing them up the stack\nconntrack nf_confirm logic cannot handle cloned skbs referencing\nthe same nf_conn entry, which will happen for multicast (broadcast)\nframes on bridges.\nExample:\nmacvlan0\n|\nbr0\n/ \\nethX ethY\nethX (or Y) receives a L2 multicast or broadcast packet containing\nan IP packet, flow is not yet in conntrack table.\n1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.\n-> skb->_nfct now references a unconfirmed entry\n2. skb is broad/mcast packet. bridge now passes clones out on each bridge\ninterface.\n3. skb gets passed up the stack.\n4. In macvlan case, macvlan driver retains clone(s) of the mcast skb\nand schedules a work queue to send them out on the lower devices.\nThe clone skb->_nfct is not a copy, it is the same entry as the\noriginal skb. The macvlan rx handler then returns RX_HANDLER_PASS.\n5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.\nThe Macvlan broadcast worker and normal confirm path will race.\nThis race will not happen if step 2 already confirmed a clone. In that\ncase later steps perform skb_clone() with skb->_nfct already confirmed (in\nhash table). This works fine.\nBut such confirmation won't happen when eb/ip/nftables rules dropped the\npackets before they reached the nf_confirm step in postrouting.\nPablo points out that nf_conntrack_bridge doesn't allow use of stateful\nnat, so we can safely discard the nf_conn entry and let inet call\nconntrack again.\nThis doesn't work for bridge netfilter: skb could have a nat\ntransformation. Also bridge nf prevents re-invocation of inet prerouting\nvia 'sabotage_in' hook.\nWork around this problem by explicit confirmation of the entry at LOCAL_IN\ntime, before upper layer has a chance to clone the unconfirmed entry.\nThe downside is that this disables NAT and conntrack helpers.\nAlternative fix would be to add locking to all code parts that deal with\nunconfirmed packets, but even if that could be done in a sane way this\nopens up other problems, for example:\n-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4\n-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5\nFor multicast case, only one of such conflicting mappings will be\ncreated, conntrack only handles 1:1 NAT mappings.\nUsers should set create a setup that explicitly marks such traffic\nNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass\nthem, ruleset might have accept rules for untracked traffic already,\nso user-visible behaviour would change.
See more information about CVE-2024-27415 from MITRE CVE dictionary and NIST NVD
NOTE: The following CVSS v3.1 metrics and score provided are preliminary and subject to review.
Base Score: | 5.5 | CVSS Vector: | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H |
Attack Vector: | Local network | Attack Complexity: | Low |
Privileges Required: | Low | User Interaction: | None |
Scope: | Unchanged | Confidentiality Impact: | None |
Integrity Impact: | None | Availability Impact: | High |
Platform | Errata | Release Date |
Oracle Linux version 9 (kernel) | ELSA-2024-5928 | 2024-08-28 |
This page is generated automatically and has not been checked for errors or omissions. For clarification or corrections: