CVE-2024-50045

netfilter: br_netfilter: fix panic with metadata_dst skb

MEDIUM
5.5
CVSS Score
Published: October 21, 2024 at 07:39 PM UTC
Updated: October 15, 2026 at 01:19 AM UTC
15 products affected across 2 vendorsLinux KernelSIMATIC S7-1500 CPU 1518-4 Pn /dp MFP FirmwareSiplus S7-1500 CPU 1518-4 Pn /dp MFP Firmware

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.6%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

4.11 ≤ v < 5.10.2275.11 ≤ v < 5.15.1685.16 ≤ v < 6.1.1136.2 ≤ v < 6.6.576.7 ≤ v < 6.11.411538d039ac6efcf4f1a6c536e1b87cd3668a9fd6.126.12 rc16.12 rc2
Vendor states this is fixed in 3453f5839420bfbb85c86c61e49f49ffd0f041c4 (fixed)
Vendor states this is fixed in 75dfcb758015c97e1accd6340691fca67d363bed (fixed)
Vendor states this is fixed in 78ed917133b118661e1fe62d4a85d5d428ee9568 (fixed)
Vendor states this is fixed in 915717e0bb9837cc5c101bc545af487bd787239e (fixed)
Vendor states this is fixed in 95c0cff5a1a5d28bf623b92eb5d1a8f56ed30803 (fixed)
Vendor states this is fixed in cce8419b8168f6e7eb637103a47f916f3de8bc81 (fixed)
Vendor states this is fixed in f07131239a76cc10d5e82c19d91f53cb55727297 (fixed)
Vendor states this is fixed in f9ff7665cd128012868098bbd07e28993e314fdb (fixed)
Vendor states this is fixed in 4.11 (unaffected)
Vendor states this is fixed in 4.19.323 (unaffected)
Vendor states this is fixed in 5.10.227 (unaffected)
Vendor states this is fixed in 5.15.168 (unaffected)
Vendor states this is fixed in 5.4.285 (unaffected)
Vendor states this is fixed in 6.1.113 (unaffected)
Vendor states this is fixed in 6.11.4 (unaffected)
Vendor states this is fixed in 6.12 (unaffected)
Vendor states this is fixed in 6.6.57 (unaffected)
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement
v < V3.2
Affected range stops below V3.2, so it looks safe — our inference, not a vendor statement

References (13)

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-476

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card