<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T19:06:55.534400+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2024-50045</id>
    <title>CVE-2024-50045 — netfilter: br_netfilter: fix panic with metadata_dst skb</title>
    <updated>2026-10-05T19:06:55.552251+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux, Siemens RUGGEDCOM RST2428P, Siemens SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 family, Siemens SCALANCE XCM-/XRM-/XCH-/XRH-300 family, Siemens SIMATIC S7-1500 TM MFP - GNU/Linux subsystem, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>netfilter: br_netfilter: fix panic with metadata_dst skb</p>
<p>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.</p>
<p>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</p>
<p>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-&gt;dst.dev is NULL.</p>
<p>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.</p>
<p>The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
with valid dst-&gt;dev, thus the crash.</p>
<p>This case was never supported in the first place, so drop the packet
instead.</p>
<p>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 = 0x0000000…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2024-50045"/>
  </entry>
</feed>
