CVE-2025-39901
Publication date:
01/10/2025
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
i40e: remove read access to debugfs files<br />
<br />
The &#39;command&#39; and &#39;netdev_ops&#39; debugfs files are a legacy debugging<br />
interface supported by the i40e driver since its early days by commit<br />
02e9c290814c ("i40e: debugfs interface").<br />
<br />
Both of these debugfs files provide a read handler which is mostly useless,<br />
and which is implemented with questionable logic. They both use a static<br />
256 byte buffer which is initialized to the empty string. In the case of<br />
the &#39;command&#39; file this buffer is literally never used and simply wastes<br />
space. In the case of the &#39;netdev_ops&#39; file, the last command written is<br />
saved here.<br />
<br />
On read, the files contents are presented as the name of the device<br />
followed by a colon and then the contents of their respective static<br />
buffer. For &#39;command&#39; this will always be ": ". For &#39;netdev_ops&#39;,<br />
this will be ": ". But note the buffer is<br />
shared between all devices operated by this module. At best, it is mostly<br />
meaningless information, and at worse it could be accessed simultaneously<br />
as there doesn&#39;t appear to be any locking mechanism.<br />
<br />
We have also recently received multiple reports for both read functions<br />
about their use of snprintf and potential overflow that could result in<br />
reading arbitrary kernel memory. For the &#39;command&#39; file, this is definitely<br />
impossible, since the static buffer is always zero and never written to.<br />
For the &#39;netdev_ops&#39; file, it does appear to be possible, if the user<br />
carefully crafts the command input, it will be copied into the buffer,<br />
which could be large enough to cause snprintf to truncate, which then<br />
causes the copy_to_user to read beyond the length of the buffer allocated<br />
by kzalloc.<br />
<br />
A minimal fix would be to replace snprintf() with scnprintf() which would<br />
cap the return to the number of bytes written, preventing an overflow. A<br />
more involved fix would be to drop the mostly useless static buffers,<br />
saving 512 bytes and modifying the read functions to stop needing those as<br />
input.<br />
<br />
Instead, lets just completely drop the read access to these files. These<br />
are debug interfaces exposed as part of debugfs, and I don&#39;t believe that<br />
dropping read access will break any script, as the provided output is<br />
pretty useless. You can find the netdev name through other more standard<br />
interfaces, and the &#39;netdev_ops&#39; interface can easily result in garbage if<br />
you issue simultaneous writes to multiple devices at once.<br />
<br />
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to<br />
refactor its write function to avoid using the static buffer. Instead, use<br />
the same logic as the i40e_dbg_command_write, with an allocated buffer.<br />
Update the code to use this instead of the static buffer, and ensure we<br />
free the buffer on exit. This fixes simultaneous writes to &#39;netdev_ops&#39; on<br />
multiple devices, and allows us to remove the now unused static buffer<br />
along with removing the read access.
Severity CVSS v4.0: Pending analysis
Last modification:
14/01/2026
