CVE-2025-39835

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: do not propagate ENODATA disk errors into xattr code<br /> <br /> ENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;<br /> namely, that the requested attribute name could not be found.<br /> <br /> However, a medium error from disk may also return ENODATA. At best,<br /> this medium error may escape to userspace as "attribute not found"<br /> when in fact it&amp;#39;s an IO (disk) error.<br /> <br /> At worst, we may oops in xfs_attr_leaf_get() when we do:<br /> <br /> error = xfs_attr_leaf_hasname(args, &amp;bp);<br /> if (error == -ENOATTR) {<br /> xfs_trans_brelse(args-&gt;trans, bp);<br /> return error;<br /> }<br /> <br /> because an ENODATA/ENOATTR error from disk leaves us with a null bp,<br /> and the xfs_trans_brelse will then null-deref it.<br /> <br /> As discussed on the list, we really need to modify the lower level<br /> IO functions to trap all disk errors and ensure that we don&amp;#39;t let<br /> unique errors like this leak up into higher xfs functions - many<br /> like this should be remapped to EIO.<br /> <br /> However, this patch directly addresses a reported bug in the xattr<br /> code, and should be safe to backport to stable kernels. A larger-scope<br /> patch to handle more unique errors at lower levels can follow later.<br /> <br /> (Note, prior to 07120f1abdff we did not oops, but we did return the<br /> wrong error code to userspace.)