CVE-2025-39901

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: remove read access to debugfs files<br /> <br /> The &amp;#39;command&amp;#39; and &amp;#39;netdev_ops&amp;#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 &amp;#39;command&amp;#39; file this buffer is literally never used and simply wastes<br /> space. In the case of the &amp;#39;netdev_ops&amp;#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 &amp;#39;command&amp;#39; this will always be ": ". For &amp;#39;netdev_ops&amp;#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&amp;#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 &amp;#39;command&amp;#39; file, this is definitely<br /> impossible, since the static buffer is always zero and never written to.<br /> For the &amp;#39;netdev_ops&amp;#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&amp;#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 &amp;#39;netdev_ops&amp;#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 &amp;#39;netdev_ops&amp;#39; on<br /> multiple devices, and allows us to remove the now unused static buffer<br /> along with removing the read access.