https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 19:46:42 +0000 https://vulnerability.circl.lu/vuln/cve-2025-39901 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>i40e: remove read access to debugfs files</p> <p>The &#39;command&#39; and &#39;netdev_ops&#39; debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c (&#34;i40e: debugfs interface&#34;).</p> <p>Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the &#39;command&#39; file this buffer is literally never used and simply wastes space. In the case of the &#39;netdev_ops&#39; file, the last command written is saved here.</p> <p>On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For &#39;command&#39; this will always be &#34;&lt;device&gt;: &#34;. For &#39;netdev_ops&#39;, this will be &#34;&lt;device&gt;: &lt;last command written&gt;&#34;. But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn&#39;t appear to be any locking mechanism.</p> <p>We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the &#39;command&#39; file, this is definitely impossible, since the static buffer is always zero and never written to. For the &#39;netdev_ops&#39; file, it does appear to be…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>i40e: remove read access to debugfs files</p> <p>The &#39;command&#39; and &#39;netdev_ops&#39; debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c (&#34;i40e: debugfs interface&#34;).</p> <p>Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the &#39;command&#39; file this buffer is literally never used and simply wastes space. In the case of the &#39;netdev_ops&#39; file, the last command written is saved here.</p> <p>On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For &#39;command&#39; this will always be &#34;&lt;device&gt;: &#34;. For &#39;netdev_ops&#39;, this will be &#34;&lt;device&gt;: &lt;last command written&gt;&#34;. But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn&#39;t appear to be any locking mechanism.</p> <p>We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the &#39;command&#39; file, this is definitely impossible, since the static buffer is always zero and never written to. For the &#39;netdev_ops&#39; file, it does appear to be…</p> https://vulnerability.circl.lu/vuln/cve-2025-39901