https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-1853 Lustre <p>In osd_scrub_setup(), id variable is of type 'struct osd_inode_id *' (size 8). But then this variable is passed to __osd_oi_lookup(), and in this function, it is passed to osd_oi_iam_lookup(), which casts it to a 'struct dt_rec *'. Then it is passed to osd_fid_unpack() by casting it to 'struct lu_fid *'. And at last, inside this function, a memcpy() is performed considering the variable is of type 'struct lu_fid *', which is of size 16.<br/> So we are accessing memory beyond what was allocated for that variable.</p> <p>I do not know how to fix this issue, as it is quite complex.</p> LU-1853

'out-of-bounds access' error in osd_scrub_setup()

Technical task LU-2753 Major Resolved Won't Fix nasf Sebastien Buisson build coverity Fri, 7 Sep 2012 04:07:49 +0000 Fri, 4 Oct 2013 19:59:11 +0000 Fri, 19 Oct 2012 02:25:24 +0000 Lustre 2.4.0 0 6 <p>This bug is in the OI Scrub code, but I think there is also a problem with the API itself that allows this kind of problem to be introduced.</p> <p>Firstly, the requirement to always cast to <tt>(struct dt_key *)</tt> means that any compiler type checking is disabled, and there is no way for the compiler or lower layers of the code to detect whether the caller is passing the correct pointer for the underlying index. It would be much safer if struct dt_key were a real structure like:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">struct dt_key { void *dtk_key; <span class="code-object">int</span> dtk_len; }; </pre> </div></div> <p>so that the key size is passed up and down the whole stack. This would also avoid the need to cast arguments everywhere (which in itself is evil) since that breaks the ability of the compiler to check the code correctness. Instead, the caller would allocate a dt_key on the stack, assign the key pointer to dtk_key, and the length to dtk_len, and the parameter type to the function would be correct.</p> <p>It's 8 more bytes on the stack at the top-level calling function, but infinitely more robustness inside the code. I don't know if there is some value to including an "int dtk_type" field as well, since the caller <em>should</em> know what type of index is being accessed, but it is an idea that crossed my mind and there are 4 free bytes in the struct that would otherwise go unused.</p> <p>Another potential issue is that even after the code to accept a proper struct dt_key, this code will need close examination to ensure that all existing callers actually pass a proper dt_key instead of the current practice of typecasting. It probably makes sense to use a slightly different name for the structure, so that in-flight patches will get a compiler warning if they are still using the old practice of "(struct dt_key *)&amp;key" instead of filling in the key properly:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">struct dt_keylen { void *dtk_key; <span class="code-object">int</span> dtk_len; }; </pre> </div></div> <p>or possibly a better name than "dt_keylen" could be found.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">static</span> <span class="code-object">int</span> osd_oi_iam_lookup(struct osd_thread_info *oti, struct osd_oi *oi, struct dt_rec *rec, <span class="code-keyword">const</span> struct dt_key *key) { ... rc = iam_it_get(it, (struct iam_key *)key); <span class="code-keyword">if</span> (rc &gt;= 0) { <span class="code-keyword">if</span> (S_ISDIR(oi-&gt;oi_inode-&gt;i_mode)) iam_rec = (struct iam_rec *)oti-&gt;oti_ldp; <span class="code-keyword">else</span> iam_rec = (struct iam_rec *)rec; iam_reccpy(&amp;it-&gt;ii_path.ip_leaf, (struct iam_rec *)iam_rec); ===&gt; <span class="code-keyword">if</span> (S_ISDIR(oi-&gt;oi_inode-&gt;i_mode)) osd_fid_unpack((struct lu_fid *)rec, (struct osd_fid_pack *)iam_rec); } ... } </pre> </div></div> <p>In this case, the IAM container is an OI index file, which is NOT directory, so the branch for "if (S_ISDIR(oi-&gt;oi_inode-&gt;i_mode))" in above code section will be skipped for the call trace: osd_scrub_setup() =&gt; __osd_oi_lookup() =&gt; osd_oi_iam_lookup(). So the OI scrub should not trigger "out-of-bounds access" error.</p> <p>Sebastien, have you hit such failure during any test? or thought there may be potential issues by analyzing code?</p> <p>Hi Yong Fan,</p> <p>This issue was found by the static code analysis tool named Coverity.</p> <p>According to your analysis, osd_fid_unpack() will not be called because the condition above will evaluate to false. But maybe there is another call path leading to the issue described here?</p> <p>Sebastien.</p> <p>Originally, the IAM was designed not only for index file, such as OI files, and quota files, but also for storing directory under Lustre namespace. But the later use case is not valid since Lustre-2.0, that means the "if (S_ISDIR(oi-&gt;oi_inode-&gt;i_mode))" branch will not be trigger anymore in current 2.x code. So I think there will not be out-of-bounds" issues in IAM according to current use cases.</p> <p>OK I understand.<br/> So maybe in that case, it would be better to remove this 'dead' branch, right?</p> <p>Yes, there are some dead codes in IAM, not only for this, but also for LVAR part. But nobody knows whether they will be re-used in the future or not, so these codes keep there since the beginning.</p> <p>It will not cause issues under current use mode.</p> Development Rank 1|hzvgkn: Rank (Obsolete) 6334