CVE-2025-71074

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> functionfs: fix the open/removal races<br /> <br /> ffs_epfile_open() can race with removal, ending up with file-&gt;private_data<br /> pointing to freed object.<br /> <br /> There is a total count of opened files on functionfs (both ep0 and<br /> dynamic ones) and when it hits zero, dynamic files get removed.<br /> Unfortunately, that removal can happen while another thread is<br /> in ffs_epfile_open(), but has not incremented the count yet.<br /> In that case open will succeed, leaving us with UAF on any subsequent<br /> read() or write().<br /> <br /> The root cause is that ffs-&gt;opened is misused; atomic_dec_and_test() vs.<br /> atomic_add_return() is not a good idea, when object remains visible all<br /> along.<br /> <br /> To untangle that<br /> * serialize openers on ffs-&gt;mutex (both for ep0 and for dynamic files)<br /> * have dynamic ones use atomic_inc_not_zero() and fail if we had<br /> zero -&gt;opened; in that case the file we are opening is doomed.<br /> * have the inodes of dynamic files marked on removal (from the<br /> callback of simple_recursive_removal()) - clear -&gt;i_private there.<br /> * have open of dynamic ones verify they hadn&amp;#39;t been already removed,<br /> along with checking that state is FFS_ACTIVE.