CVE-2024-57952

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "libfs: fix infinite directory reads for offset dir"<br /> <br /> The current directory offset allocator (based on mtree_alloc_cyclic)<br /> stores the next offset value to return in octx-&gt;next_offset. This<br /> mechanism typically returns values that increase monotonically over<br /> time. Eventually, though, the newly allocated offset value wraps<br /> back to a low number (say, 2) which is smaller than other already-<br /> allocated offset values.<br /> <br /> Yu Kuai reports that, after commit 64a7ce76fb90<br /> ("libfs: fix infinite directory reads for offset dir"), if a<br /> directory&amp;#39;s offset allocator wraps, existing entries are no longer<br /> visible via readdir/getdents because offset_readdir() stops listing<br /> entries once an entry&amp;#39;s offset is larger than octx-&gt;next_offset.<br /> These entries vanish persistently -- they can be looked up, but will<br /> never again appear in readdir(3) output.<br /> <br /> The reason for this is that the commit treats directory offsets as<br /> monotonically increasing integer values rather than opaque cookies,<br /> and introduces this comparison:<br /> <br /> if (dentry2offset(dentry) &gt;= last_index) {<br /> <br /> On 64-bit platforms, the directory offset value upper bound is<br /> 2^63 - 1. Directory offsets will monotonically increase for millions<br /> of years without wrapping.<br /> <br /> On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator<br /> can wrap after only a few weeks (at worst).<br /> <br /> Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for<br /> offset dir") to prepare for a fix that can work properly on 32-bit<br /> systems and might apply to recent LTS kernels where shmem employs<br /> the simple_offset mechanism.