<?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://db.gcve.eu</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, 09 Oct 2026 12:01:12 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-98377</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98377</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vlan: require the MAC header to be present in __vlan_insert_inner_tag()&lt;/p&gt;
&lt;p&gt;__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),
never that mac_len bytes of MAC header are present.  Its ETH_HLEN
wrappers - __vlan_insert_tag() under skb_vlan_push(), and
vlan_insert_tag() under validate_xmit_vlan() on the generic transmit
path - therefore rewrite the first 16 bytes at skb-&amp;gt;data: a 12-byte
memmove plus two 2-byte stores at +12 and +14.  No caller supplies the
bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().&lt;/p&gt;
&lt;p&gt;An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a
one-byte AF_PACKET/SOCK_RAW frame.  The first vlan push only sets a
hwaccel tag; the next - clsact &amp;#34;action vlan push&amp;#34; or
bpf_skb_vlan_push() - enters the helper with skb-&amp;gt;len still 1.  The
head comes from skbuff_small_head without __GFP_ZERO, so each push
drags bytes from beyond skb-&amp;gt;tail into the frame.  After three the
one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised
slab:&lt;/p&gt;
&lt;p&gt;0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81
           `------------------------------&amp;#39;
  only 0x5a was sent; the rest is slab, here the top 56 bits of a
  linear-map address&lt;/p&gt;
&lt;p&gt;Require the MAC header the helper rewrites to be present, so such a
frame is dropped rather than transmitted.&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;vlan: require the MAC header to be present in __vlan_insert_inner_tag()&lt;/p&gt;
&lt;p&gt;__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),
never that mac_len bytes of MAC header are present.  Its ETH_HLEN
wrappers - __vlan_insert_tag() under skb_vlan_push(), and
vlan_insert_tag() under validate_xmit_vlan() on the generic transmit
path - therefore rewrite the first 16 bytes at skb-&amp;gt;data: a 12-byte
memmove plus two 2-byte stores at +12 and +14.  No caller supplies the
bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().&lt;/p&gt;
&lt;p&gt;An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a
one-byte AF_PACKET/SOCK_RAW frame.  The first vlan push only sets a
hwaccel tag; the next - clsact &amp;#34;action vlan push&amp;#34; or
bpf_skb_vlan_push() - enters the helper with skb-&amp;gt;len still 1.  The
head comes from skbuff_small_head without __GFP_ZERO, so each push
drags bytes from beyond skb-&amp;gt;tail into the frame.  After three the
one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised
slab:&lt;/p&gt;
&lt;p&gt;0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81
           `------------------------------&amp;#39;
  only 0x5a was sent; the rest is slab, here the top 56 bits of a
  linear-map address&lt;/p&gt;
&lt;p&gt;Require the MAC header the helper rewrites to be present, so such a
frame is dropped rather than transmitted.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-98377</guid>
    </item>
    <item>
      <title>GHSA-jjqx-7ghh-p62x</title>
      <link>https://db.gcve.eu/vuln/ghsa-jjqx-7ghh-p62x</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vlan: require the MAC header to be present in __vlan_insert_inner_tag()&lt;/p&gt;
&lt;p&gt;__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),
never that mac_len bytes of MAC header are present.  Its ETH_HLEN
wrappers - __vlan_insert_tag() under skb_vlan_push(), and
vlan_insert_tag() under validate_xmit_vlan() on the generic transmit
path - therefore rewrite the first 16 bytes at skb-&amp;gt;data: a 12-byte
memmove plus two 2-byte stores at +12 and +14.  No caller supplies the
bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().&lt;/p&gt;
&lt;p&gt;An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a
one-byte AF_PACKET/SOCK_RAW frame.  The first vlan push only sets a
hwaccel tag; the next - clsact &amp;#34;action vlan push&amp;#34; or
bpf_skb_vlan_push() - enters the helper with skb-&amp;gt;len still 1.  The
head comes from skbuff_small_head without __GFP_ZERO, so each push
drags bytes from beyond skb-&amp;gt;tail into the frame.  After three the
one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised
slab:&lt;/p&gt;
&lt;p&gt;0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81
           `------------------------------&amp;#39;
  only 0x5a was sent; the rest is slab, here the top 56 bits of a
  linear-map address&lt;/p&gt;
&lt;p&gt;Require the MAC header the helper rewrites to be present, so such a
frame is dropped rather than transmitted.&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;vlan: require the MAC header to be present in __vlan_insert_inner_tag()&lt;/p&gt;
&lt;p&gt;__vlan_insert_inner_tag() only guarantees head room via skb_cow_head(),
never that mac_len bytes of MAC header are present.  Its ETH_HLEN
wrappers - __vlan_insert_tag() under skb_vlan_push(), and
vlan_insert_tag() under validate_xmit_vlan() on the generic transmit
path - therefore rewrite the first 16 bytes at skb-&amp;gt;data: a 12-byte
memmove plus two 2-byte stores at +12 and +14.  No caller supplies the
bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().&lt;/p&gt;
&lt;p&gt;An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a
one-byte AF_PACKET/SOCK_RAW frame.  The first vlan push only sets a
hwaccel tag; the next - clsact &amp;#34;action vlan push&amp;#34; or
bpf_skb_vlan_push() - enters the helper with skb-&amp;gt;len still 1.  The
head comes from skbuff_small_head without __GFP_ZERO, so each push
drags bytes from beyond skb-&amp;gt;tail into the frame.  After three the
one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised
slab:&lt;/p&gt;
&lt;p&gt;0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81
           `------------------------------&amp;#39;
  only 0x5a was sent; the rest is slab, here the top 56 bits of a
  linear-map address&lt;/p&gt;
&lt;p&gt;Require the MAC header the helper rewrites to be present, so such a
frame is dropped rather than transmitted.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-jjqx-7ghh-p62x</guid>
    </item>
  </channel>
</rss>
