<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 12:25:02 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-06767</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-06767</link>
      <description>bdu:2025-06767</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-06767</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53053</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53053</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-53053</guid>
    </item>
    <item>
      <title>EUVD-2026-311812</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311812</link>
      <description>EUVD-2026-311812</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311812</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53053</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53053</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;erspan: do not use skb_mac_header() in ndo_start_xmit()&lt;/p&gt;
&lt;p&gt;Drivers should not assume skb_mac_header(skb) == skb-&amp;gt;data in their
ndo_start_xmit().&lt;/p&gt;
&lt;p&gt;Use skb_network_offset() and skb_transport_offset() which
better describe what is needed in erspan_fb_xmit() and
ip6erspan_tunnel_xmit()&lt;/p&gt;
&lt;p&gt;syzbot reported:
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Modules linked in:
CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 &amp;lt;0f&amp;gt; 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00
RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003
RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00
R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff88802340800…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;erspan: do not use skb_mac_header() in ndo_start_xmit()&lt;/p&gt;
&lt;p&gt;Drivers should not assume skb_mac_header(skb) == skb-&amp;gt;data in their
ndo_start_xmit().&lt;/p&gt;
&lt;p&gt;Use skb_network_offset() and skb_transport_offset() which
better describe what is needed in erspan_fb_xmit() and
ip6erspan_tunnel_xmit()&lt;/p&gt;
&lt;p&gt;syzbot reported:
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Modules linked in:
CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 &amp;lt;0f&amp;gt; 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00
RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003
RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00
R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff88802340800…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53053</guid>
    </item>
    <item>
      <title>GHSA-hhvq-g7gp-5v2c</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hhvq-g7gp-5v2c</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;erspan: do not use skb_mac_header() in ndo_start_xmit()&lt;/p&gt;
&lt;p&gt;Drivers should not assume skb_mac_header(skb) == skb-&amp;gt;data in their
ndo_start_xmit().&lt;/p&gt;
&lt;p&gt;Use skb_network_offset() and skb_transport_offset() which
better describe what is needed in erspan_fb_xmit() and
ip6erspan_tunnel_xmit()&lt;/p&gt;
&lt;p&gt;syzbot reported:
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Modules linked in:
CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 &amp;lt;0f&amp;gt; 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00
RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003
RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00
R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff88802340800…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;erspan: do not use skb_mac_header() in ndo_start_xmit()&lt;/p&gt;
&lt;p&gt;Drivers should not assume skb_mac_header(skb) == skb-&amp;gt;data in their
ndo_start_xmit().&lt;/p&gt;
&lt;p&gt;Use skb_network_offset() and skb_transport_offset() which
better describe what is needed in erspan_fb_xmit() and
ip6erspan_tunnel_xmit()&lt;/p&gt;
&lt;p&gt;syzbot reported:
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]
WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Modules linked in:
CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962
Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 &amp;lt;0f&amp;gt; 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00
RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003
RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00
R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff88802340800…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hhvq-g7gp-5v2c</guid>
    </item>
    <item>
      <title>OESA-2025-1726 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1726</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kcm: close race conditions on sk_receive_queue&lt;/p&gt;
&lt;p&gt;sk-&amp;amp;gt;sk_receive_queue is protected by skb queue lock, but for KCM
sockets its RX path takes mux-&amp;amp;gt;rx_lock to protect more than just
skb queue. However, kcm_recvmsg() still only grabs the skb queue
lock, so race conditions still exist.&lt;/p&gt;
&lt;p&gt;We can teach kcm_recvmsg() to grab mux-&amp;amp;gt;rx_lock too but this would
introduce a potential performance regression as struct kcm_mux can
be shared by multiple KCM sockets.&lt;/p&gt;
&lt;p&gt;So we have to enforce skb queue lock in requeue_rx_msgs() and handle
skb peek case carefully in kcm_wait_data(). Fortunately,
skb_recv_datagram() already handles it nicely and is widely used by
other sockets, we can just switch to skb_recv_datagram() after
getting rid of the unnecessary sock lock in kcm_recvmsg() and
kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,
so it is safe to get rid of this check too.&lt;/p&gt;
&lt;p&gt;I ran the original syzbot reproducer for 30 min without seeing any
issue.(CVE-2022-49814)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipvs: fix WARNING in ip_vs_app_net_cleanup()&lt;/p&gt;
&lt;p&gt;During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn&amp;amp;apos;t be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.&lt;/p&gt;
&lt;p&gt;T…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kcm: close race conditions on sk_receive_queue&lt;/p&gt;
&lt;p&gt;sk-&amp;amp;gt;sk_receive_queue is protected by skb queue lock, but for KCM
sockets its RX path takes mux-&amp;amp;gt;rx_lock to protect more than just
skb queue. However, kcm_recvmsg() still only grabs the skb queue
lock, so race conditions still exist.&lt;/p&gt;
&lt;p&gt;We can teach kcm_recvmsg() to grab mux-&amp;amp;gt;rx_lock too but this would
introduce a potential performance regression as struct kcm_mux can
be shared by multiple KCM sockets.&lt;/p&gt;
&lt;p&gt;So we have to enforce skb queue lock in requeue_rx_msgs() and handle
skb peek case carefully in kcm_wait_data(). Fortunately,
skb_recv_datagram() already handles it nicely and is widely used by
other sockets, we can just switch to skb_recv_datagram() after
getting rid of the unnecessary sock lock in kcm_recvmsg() and
kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,
so it is safe to get rid of this check too.&lt;/p&gt;
&lt;p&gt;I ran the original syzbot reproducer for 30 min without seeing any
issue.(CVE-2022-49814)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipvs: fix WARNING in ip_vs_app_net_cleanup()&lt;/p&gt;
&lt;p&gt;During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn&amp;amp;apos;t be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.&lt;/p&gt;
&lt;p&gt;T…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1726</guid>
    </item>
    <item>
      <title>RHSA-2023:6583 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2023:6583</link>
      <description>&lt;p&gt;kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2023:6583</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53053</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53053</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 126 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: erspan: do not use skb_mac_header() in ndo_start_xmit() Drivers should not assume skb_mac_header(skb) == skb-&amp;gt;data in their ndo_start_xmit(). Use skb_network_offset() and skb_transport_offset() which better describe what is needed in erspan_fb_xmit() and ip6erspan_tunnel_xmit() syzbot reported: WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline] WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962 Modules linked in: CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline] RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962 Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 &amp;lt;0f&amp;gt; 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00 RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000 RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003 RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00 R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000 FS…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 126 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: erspan: do not use skb_mac_header() in ndo_start_xmit() Drivers should not assume skb_mac_header(skb) == skb-&amp;gt;data in their ndo_start_xmit(). Use skb_network_offset() and skb_transport_offset() which better describe what is needed in erspan_fb_xmit() and ip6erspan_tunnel_xmit() syzbot reported: WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline] WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962 Modules linked in: CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline] RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962 Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 &amp;lt;0f&amp;gt; 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00 RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000 RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003 RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00 R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000 FS…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53053</guid>
    </item>
  </channel>
</rss>
