<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/75632>75632</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            LLVM IR operand accessors need stronger protections against OOB accesses
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          rnk
      </td>
    </tr>
</table>

<pre>
    All `llvm::User` objects store an array of `llvm::Use` objects representing the operands, either co-allocated preceding the User object, or in a separate, so-called "hung off" allocation. While we have bounds check assertions in [User::getOperand(unsigned)](https://github.com/llvm/llvm-project/blob/67aec2f58bf1568bb1c68d4906bc3c0103ff3c98/llvm/include/llvm/IR/User.h#L170), the fixed operand accessors (`Op<0>()`) do not ultimately have such a bounds check. They ultimately call [OpFrom](https://github.com/llvm/llvm-project/blob/67aec2f58bf1568bb1c68d4906bc3c0103ff3c98/llvm/include/llvm/IR/User.h#L127), which could check the bounds of the index against `OpTraits<U>::operands()`. This seems like a common sense safety check, and we should just add it, although it won't catch code which iterates past the end of the operand list because our iterators are pointers. If we want to defend against that kind of error, we could turn [User::op_iterator](https://github.com/llvm/llvm-project/blob/67aec2f58bf1568bb1c68d4906bc3c0103ff3c98/llvm/include/llvm/IR/User.h#L229) into a wrapped iterator that carries a `User*` and index, or something equivalent.

Currently, ASan and other dynamic instrumentation bounds checking tools are blind to this category of OOB access for Users that co-allocate the operand list with the User, and iterating one past the end of the use list reads memory from the User instead of reading from the red zones which would detect the OOB access.

I think the simplest way to catch these errors would be to disable operand co-allocation with ASan and other tools, and use hung-off uses for all kinds of users, even fixed operands. However, this probably creates significant code complexity, and blinds us to Asan bugs in the Use co-allocation codepath.

An alternative approach would be to co-allocate an extra `Use` in the operand list when ASan is enabled, and poison it using the ASan API. Between the two approaches to fixing ASan blindness, I think I favor the second.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzMlkFz27gOxz8NfcHEI1OxYx98cNLneZnpm7zptrvHHYiELDYSqSWoON5PvwNKipu2l731koxkEgR--ONPIbM7eaK9Wt-r9YcFDqkJcR_986IK9rI_tC2oTdG2L50qD6o8fGGKalNAqL6SSQycQiRADxgjXiDUPyz_dnWkPhKTT86fIDUEoaeI3rLSD0AuNRTBhBts22AwkYU-kiE7r5bDp1iyIURwHhCYeoyYSN5xuDHYtmRBad0M_gShrpXWMMV0wS_hj8a1BGeCBl8IqjB4y2AaMs-AzBRlFUtstb7PBedaTpSexnSV3g4-g7NK79T6g9LbJqWeZaE-Kn08udQM1dKETuljxjH-u-ljGNM_Vm2olD5u7pCMrtfbql6tN9uqWpnN1t7uik1lSlOsirKuS7PbXuM4b9rB0vXF4yelj5LnslG6_Li6KyQr_ZCZ1e6V7MwZ0BhiDpFB6a3aFE-9Kh8KVf5HHvVObWQr2AA-JBja5DpM1F5GUDyYBvAdryV8bujy7UqhL9ye-mMM3S_HRt9NbM6NMw2YMLR2ar3QmmoLdX5y3tIr4Amd5wQZ1-eILrEqH74ItKyLq4YnhALFMTBRx9C6ZwIEE7oueGDyTMBYU7qMx0ou0pkzATc5m68DJ0BrwWWVY5uaMJwacAnOwSt9l8BgyslbmupwiWQCGHrklHMnb-cy5ua3jhNUZHBggjDEaZeoASNBH5xPFHkJj7Wkc0afIAWwVEuwGUNqMMGzG8NTjCFmnDSxTEP8bm5C_-d80K8mBy1a2IHzKQDCOWLfk33DMpZqMEZHDCgCyFXpg3iaEM0CmayIQ0epEauivwb3gi35tFTFB1Ucxr8PQ4zkU3uRDYffxDMFYjY9e_HYOQNCOA4d-ZSt6t2sZRcMoR27VbXSghQgidbELU8hZgN-erqf5hzqELNp8lTK1Vp_FMbZpebNZWdVjijk5ODpp-ISLeX9kdAydNRJGnUM3dWypSrCvEVWSbi3BZEs_B088aTkc1aRpURmPOtazjuaj1K4H6eWXde3JDXgRZCM45EaYhoVylPYirKgHWPVXsu_YhHkmcN37cnYZyZSsdwsN6Gu5WHELLYnU5HNYxDm-U57If_egnkJ_w1nehkZ5-b1MVRYiXdGykMsV4urnZEBzENughT46tJlTiK3n2FgKejA6KEaTvnOmqh_V5WE6TE17xgevLgLRY_JvRBg38eAbz0YYX2rGfRArynOkyBTMB34XkkN-ZGgYyAvrO2cdx8cBy9eNvB8reelh_8_LuGe0ploDJnO4S0jymXW7lW25OW5fk-cKc9aeIQaX_LcEjCZ4O1yYfel3ZU7XNB-dVfozWa11uWi2VO1trjd6nK1qbW2piajdV1vt9XK2N12s3B7XehypVfr1V25Wt8usTSm2OhbfYuIBm_VbUEdunYp3rIM8bRwzAPt79abUi9arKjl_F2ltacz5B-V1vKZFffZ4aRl6rYQaHyNklxqaf_x4-__g8dPP7m5PZEFTjH4E0URj4xK_mKZLfo6MsSLIbb7f-24OVlW-piL-ScAAP__QnZvog">