<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 15:14:35 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-90083 — net/sched: act_ife: Only operate on Ethernet frames</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-90083</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/sched: act_ife: Only operate on Ethernet frames&lt;/p&gt;
&lt;p&gt;act_ife encapsulates/decapsulates the original Ethernet header and uses
skb-&amp;gt;dev-&amp;gt;hard_header_len as the length of that header. That is only
correct for Ethernet devices: on a device where hard_header_len does not
match the L2 header that was actually pulled (PPP reports PPP_HDRLEN
while nothing is stripped on ingress), the ingress skb_push()/skb_pull()
use the wrong length and can hit skb_under_panic when headroom is tight.&lt;/p&gt;
&lt;p&gt;IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites
h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so
instead of trying to make the offsets work for arbitrary link types,
simply drop packets that do not carry an Ethernet header.&lt;/p&gt;
&lt;p&gt;Checking skb-&amp;gt;dev-&amp;gt;type alone is not enough. We have to cater for a
corner case where mirred can redirect an skb from a non-Ethernet device
to an Ethernet one, and skb-&amp;gt;dev then says nothing about the framing the
skb actually has: an skb redirected from ppp0 reaches the target&amp;#39;s ingress
hook with mac_len 0 and no Ethernet header at all. So at ingress also
require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so
the device type is all we have; a bogus redirect there yields a malformed
frame rather than an out-of-bounds push, and it would be malformed with or
without IFE.&lt;/p&gt;
&lt;p&gt;That corner case is not theoretical - redirecting from ppp0 into a veth
that has an ife en…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net/sched: act_ife: Only operate on Ethernet frames&lt;/p&gt;
&lt;p&gt;act_ife encapsulates/decapsulates the original Ethernet header and uses
skb-&amp;gt;dev-&amp;gt;hard_header_len as the length of that header. That is only
correct for Ethernet devices: on a device where hard_header_len does not
match the L2 header that was actually pulled (PPP reports PPP_HDRLEN
while nothing is stripped on ingress), the ingress skb_push()/skb_pull()
use the wrong length and can hit skb_under_panic when headroom is tight.&lt;/p&gt;
&lt;p&gt;IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites
h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so
instead of trying to make the offsets work for arbitrary link types,
simply drop packets that do not carry an Ethernet header.&lt;/p&gt;
&lt;p&gt;Checking skb-&amp;gt;dev-&amp;gt;type alone is not enough. We have to cater for a
corner case where mirred can redirect an skb from a non-Ethernet device
to an Ethernet one, and skb-&amp;gt;dev then says nothing about the framing the
skb actually has: an skb redirected from ppp0 reaches the target&amp;#39;s ingress
hook with mac_len 0 and no Ethernet header at all. So at ingress also
require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so
the device type is all we have; a bogus redirect there yields a malformed
frame rather than an out-of-bounds push, and it would be malformed with or
without IFE.&lt;/p&gt;
&lt;p&gt;That corner case is not theoretical - redirecting from ppp0 into a veth
that has an ife en…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-90083</guid>
    </item>
  </channel>
</rss>
