<?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>Fri, 02 Oct 2026 18:56:02 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-21922 — ppp: Fix KMSAN uninit-value warning with bpf</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-21922</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;ppp: Fix KMSAN uninit-value warning with bpf&lt;/p&gt;
&lt;p&gt;Syzbot caught an &amp;#34;KMSAN: uninit-value&amp;#34; warning [1], which is caused by the
ppp driver not initializing a 2-byte header when using socket filter.&lt;/p&gt;
&lt;p&gt;The following code can generate a PPP filter BPF program:
&amp;#39;&amp;#39;&amp;#39;
struct bpf_program fp;
pcap_t *handle;
handle = pcap_open_dead(DLT_PPP_PPPD, 65535);
pcap_compile(handle, &amp;amp;fp, &amp;#34;ip and outbound&amp;#34;, 0, 0);
bpf_dump(&amp;amp;fp, 1);
&amp;#39;&amp;#39;&amp;#39;
Its output is:
&amp;#39;&amp;#39;&amp;#39;
(000) ldh [2]
(001) jeq #0x21 jt 2 jf 5
(002) ldb [0]
(003) jeq #0x1 jt 4 jf 5
(004) ret #65535
(005) ret #0
&amp;#39;&amp;#39;&amp;#39;
Wen can find similar code at the following link:
https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680
The maintainer of this code repository is also the original maintainer
of the ppp driver.&lt;/p&gt;
&lt;p&gt;As you can see the BPF program skips 2 bytes of data and then reads the
&amp;#39;Protocol&amp;#39; field to determine if it&amp;#39;s an IP packet. Then it read the first
byte of the first 2 bytes to determine the direction.&lt;/p&gt;
&lt;p&gt;The issue is that only the first byte indicating direction is initialized
in current ppp driver code while the second byte is not initialized.&lt;/p&gt;
&lt;p&gt;For normal BPF programs generated by libpcap, uninitialized data won&amp;#39;t be
used, so it&amp;#39;s not a problem. However, for carefully crafted BPF programs,
such as those generated by syzkaller [2], which start reading from offset
0, the uninitialized data will be used and caught by KMSAN.&lt;/p&gt;
&lt;p&gt;[1] https://syzkaller.appspot.com/bug?extid=8532…&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;ppp: Fix KMSAN uninit-value warning with bpf&lt;/p&gt;
&lt;p&gt;Syzbot caught an &amp;#34;KMSAN: uninit-value&amp;#34; warning [1], which is caused by the
ppp driver not initializing a 2-byte header when using socket filter.&lt;/p&gt;
&lt;p&gt;The following code can generate a PPP filter BPF program:
&amp;#39;&amp;#39;&amp;#39;
struct bpf_program fp;
pcap_t *handle;
handle = pcap_open_dead(DLT_PPP_PPPD, 65535);
pcap_compile(handle, &amp;amp;fp, &amp;#34;ip and outbound&amp;#34;, 0, 0);
bpf_dump(&amp;amp;fp, 1);
&amp;#39;&amp;#39;&amp;#39;
Its output is:
&amp;#39;&amp;#39;&amp;#39;
(000) ldh [2]
(001) jeq #0x21 jt 2 jf 5
(002) ldb [0]
(003) jeq #0x1 jt 4 jf 5
(004) ret #65535
(005) ret #0
&amp;#39;&amp;#39;&amp;#39;
Wen can find similar code at the following link:
https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680
The maintainer of this code repository is also the original maintainer
of the ppp driver.&lt;/p&gt;
&lt;p&gt;As you can see the BPF program skips 2 bytes of data and then reads the
&amp;#39;Protocol&amp;#39; field to determine if it&amp;#39;s an IP packet. Then it read the first
byte of the first 2 bytes to determine the direction.&lt;/p&gt;
&lt;p&gt;The issue is that only the first byte indicating direction is initialized
in current ppp driver code while the second byte is not initialized.&lt;/p&gt;
&lt;p&gt;For normal BPF programs generated by libpcap, uninitialized data won&amp;#39;t be
used, so it&amp;#39;s not a problem. However, for carefully crafted BPF programs,
such as those generated by syzkaller [2], which start reading from offset
0, the uninitialized data will be used and caught by KMSAN.&lt;/p&gt;
&lt;p&gt;[1] https://syzkaller.appspot.com/bug?extid=8532…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-21922</guid>
    </item>
  </channel>
</rss>
