<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=http://email.email.llvm.org/c/eJztWNtu4zgS_RrnpRBDV18e_BA73Ytg5xKkezCPBiVRNse0qCUpO9mv31OUHMdJujOzvQ8L7AaGTfFSrMupSh0VpnpajJIbfD4djO68Mk3_OIpuR9HNr19G6Q39pJrukfJxHI2nk2vNTzvlaZSkMX35-Z5-Ng39Yg40ozjC_iTGVzyn376uKImSmB5nk_Uke_Xzt19-GyWfg-hRsiLIU44EdUXX-A7nxhkVwsmKKlPupOU9R-W3uDVprTooLauNxAPJRhR46BV-6JxnlS1-S4rH-WQc48gsn0tZzUQigkbXcXwdxaNk3h_S-rCng7SOrcfhOO3nv24libbVqhTsGFawVwljvoBKK7ykUb60siraepTf4qqt962DGFiHzwY6d8W4NHs81KZRpsJg2H9SYPgOjr-VrrSqDReKwnSe_KUaL-PzWsOj6XRFWu0keUOiEfrJySDg6-qeWgFP-rMNlaz4IB5aYz17WD56K0pPB2GV6RyppjZ238vG5-4eMqsgS4unPiiqKXVXqWYTrvFlSyYo73jxyXRUigZLqtmRqdlXbfSxo3jP8D0fv_QRG-zUHhbXCnq_tL22Yi-Pxu5wm_BkpQ6mBdAo5zoZAOaoNlqbIys8CM6XiMW6NJUc-0f_oW6MluHnurXmD1l6Di0ACZM_T2dZluUZRhdCX0U6fB-3siFtxLPzLoIcUsJKjkxYPKstrTXWXcibRMMnPFq5ge63M3IeEccookIikJJmnJ-cDwV7lmxGWCWbf3RuOh_ORf25HONlOJp9eHQ2HJ3GL64MIJ51s34wx5gXkmX07KnvSJwOEpOKJaqaLOSkn8gmtDHAfVtCUjw4gx6itcXxdocozFSFYQLvmrrGKEagVvY06PbicX0QupM8k0CXFRJh3W9l4x_hviVFj9My6LxyabK-PBPEvDc7p4c46FH6x5Me0bMePFL7fT_C1uSk8lo21cfb07BdNYf7iB6y1-bGz-fSfDA3DC7MnXzb2rS3Fvfk3xGd_Zjoyfp4NmHaDzN6mK3t8ZtXTn7syvnJazFig9Xbuo2obq_zXpdo-OOpSfZmapq8mZpFJ4k99FphZeNJaCtF9URbUdE7qN4LuxuyeRZyxYla9s9xlvDEQ_Tfgd8_jd6_hN3eYwzcSyvTd7CVvrYyjfNvWhnX9ftm5nH8jplhlkF-xuHkXUh-jMfJv4fHb6DxDRbfIPENDl-icAARF_1pqMDzUIGT02r6f4j970DsVGWT_zjI0st_8_mf_DcPCUIrdHJlKZ3jrrXvUrkBOoUGHd8_5eAHjuH3ozcIfsj4vJOBV6CNdqqS3IFyLzVc0Rdpa_hmdIpIFHSzrnFshlZ79F9xby9bxL5G0fbSrVtp17yRIujrhR7maU6tFLvzE1f2Ndd-mr7bp71s--8a5ZXQQ8-u-t7z3Oj_zr3iqTtnE6Su-9a2kkW3uWjUufE0xR9Vt2_73nNFd1QyM0BbOfVUK_TwLAPsAqNyK8sdwVGycc8eOneb8N7GNJixZh-WPv30efxu88mUaAhqzURg3ROBdWvYo0uKQ5NWCS84bWk0XQ4dGv4KuAn_DoeZ0fR2YGYI3yDpBZ5eyRYs_qYE5fDUzRgAz3Le8_cdbTqGGsJ7xFEIumaWVXWWzUWP3-LWU0seaB5AGSji3QNxQw_nWHJmj1UpXKCMveRr-gI2JJ-5LGTtEY9WeC8t6GNDK1ref-aA-K1BUHpa1G9vjGddGKrhghVfi93hyvHpAuiEDhh9Bf2jU-CeAgTCc9BCLIV9GsLJEl65aeiey61oNifzQvEITO05vBrLndggSUCIW5AbdZC9xlByrzZbEEgZtG0kJw7uDNx8CwJ0MuW0wCbsBcio62xPQ9kg9EDKwSNDfjIdxp3QzFjLZGow9a5m2G7DUmBHhTm84uNNWBglCZBfbk8G80sBtF4B-OwHKbBWgvSGxD7zVdDYX--_rr_crP7eU8Yt4JCBCzunCn12zpy6gURruNwiSZtuX0B_hiKfg8m7xhybE4Z4K-MIHrHUQqpkIfBF11b8wmAgyi-DYwVHltVohsBYxa81SCPve_fL5jVJ7JOaw9GKUMGKp7Clf1_Drj5Iy0TZBtoeuDHKHQKrn8a0BNA6Lhu-a6CVDmEUVXCNCdq8vEqbjSoH5MIboRQha0UDvDlUIq2hKiodrAz8NJD9JGElcOUG3Jzd5A1SSdjw4mZ8mZTDK4IhGwPaSouaWMLfAdzXZ2Sz1JBhrUHVCnUTRXB8VS3Sap7OxZXooKZd7ORBXbuuueqsXvxlSh9eGjCnz9M4ia-2i6qosygu60TW8zyayrQQ0TybppMkm0VSRFdaFFK7xShfwr5GHvv3DhiP8turH9dALZIoSaI4jqNpkuXJuJ7WqZRlNSukLKaT-SiL5F4oPWY5Y2M3V3YRRMI7DosaeefOiwCN2jRSBoWhoVdehwcuUvltX_zY11z_L4MxlBnlnmvWKfr8QoNqKIGUvwoGLIL2_wImby5F>53121</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [BPF] rust BPF one critical bound check is opt out lead to load failure
        </td>
    </tr>

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

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

    <tr>
      <th>Reporter</th>
      <td>
          kevi-sun
      </td>
    </tr>
</table>

<pre>
    **Evolution**
OS: Linux 5.10.76-linuxkit #1 SMP Mon Nov 8 10:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux, it is a ubuntu 20.4 based docker, with "priviledge" enabled
Rust: rustc 1.56.1 (59eed8a2a 2021-11-01)
llvm version: 13
The application is based on rust crate [redbpf](https://github.com/foniod/redbpf)

**Description about the application**
The application would like to analyse the TCP packet based on dedicated port, extract various information on IP and TCP layer, including the tcp options, you can think of [p0f](https://github.com/p0f/p0f).

The simplified application framework that related with issue is as following 
[bpf_code.txt](https://github.com/llvm/llvm-project/files/7844454/bpf_code.txt)


when loading the application, it report the following errors

```
regs=8 stack=0 before 80: (bf) r4 = r5
regs=8 stack=0 before 79: (0f) r5 += r4
regs=8 stack=0 before 78: (71) r4 = *(u8 *)(r4 +0)
regs=8 stack=0 before 77: (2d) if r8 > r2 goto pc+10
 R0_r=pkt(id=2,off=14,r=14,umax_value=120,var_off=(0x0; 0x7c),s32_max_value=124,u32_max_value=124) R1_r=ctx(id=0,off=0,imm=0) R2_r=pkt_end(id=0,off=0,imm=0) R3_r=invP0 R4_r=pkt(id=1,off=35,r=35,umax_value=60,var_off=(0x0; 0x3c)) R5_r=pkt(id=1,off=34,r=35,umax_value=60,var_off=(0x0; 0x3c)) R6_w=invP0 R7=inv4 R8_rw=pkt(id=1,off=36,r=35,umax_value=60,var_off=(0x0; 0x3c)) R9_r=inv1 R10=fp0 fp-56_w=00000000 fp-64_w=00000000 fp-72_w=00000000 fp-80_r=inv
parent already had regs=8 stack=0 marks
88: safe
142: R0=pkt(id=2,off=14,r=14,umax_value=120,var_off=(0x0; 0x7c),s32_max_value=124,u32_max_value=124) R1=ctx(id=0,off=0,imm=0) R2=pkt_end(id=0,off=0,imm=0) R3=inv0 R4=pkt(id=3,off=34,r=33,umax_value=315,var_off=(0x0; 0x1ff),s32_max_value=511,u32_max_value=511) R5=invP0 R6=invP0 R7=inv4 R8=pkt(id=1,off=36,r=36,umax_value=60,var_off=(0x0; 0x3c)) R9=inv1 R10=fp0 fp-56=00000000 fp-64=00000000 fp-72=00000000 fp-80=inv
142: (b7) r9 = 2
143: R0=pkt(id=2,off=14,r=14,umax_value=120,var_off=(0x0; 0x7c),s32_max_value=124,u32_max_value=124) R1=ctx(id=0,off=0,imm=0) R2=pkt_end(id=0,off=0,imm=0) R3=inv0 R4=pkt(id=3,off=34,r=33,umax_value=315,var_off=(0x0; 0x1ff),s32_max_value=511,u32_max_value=511) R5=invP0 R6=invP0 R7=inv4 R8=pkt(id=1,off=36,r=36,umax_value=60,var_off=(0x0; 0x3c)) R9_w=inv2 R10=fp0 fp-56=00000000 fp-64=00000000 fp-72=00000000 fp-80=inv
143: (71) r5 = *(u8 *)(r4 +0)
invalid access to packet, off=34 size=1, R4(id=3,off=34,r=33)
R4 offset is outside of the packet
processed 142 insns (limit 1000000) max_states_per_insn 0 total_states 9 peak_states 9 mark_read 7
```

**Initial analysis:**
When extract the elf with debug information bpf_objdump.txt, I couldn't find the bound check setense of the following is gone from the ELF.

```rust
if tcp_option_pos + 1 > data_end {
    break;
}
let tcp_opt = *(tcp_option_pos as *const u8);
```

I guess it was opt-out during completing the rust to llvm IR code for some reason:
- Since it is a common pattern in C BPF, tho I think it is not opt out for C to BPF code.
- there are quite a lot of boundary check for tcp_option_pos before changing the values, from the language perspective, this might be not necessary, while it is necessary to make sure the BPF register offset/range correct
- If I change the above application in the "match tcp_opt" part, for each cases (including TCPOPT_SACK that has 4 possible values) use the literal number (that is known during the compiler phase) to update the tcp_option_pos rather than the variable len , then the application could be passed by the Linux BPF verifier and work properly. But unfortunately, adding other application logic, those extra branches will lead to error of "BPF program is too large".

I think opt-out this critical bound-check for BPF is a potential bug.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJztWNlu4zgW_Rrn5SKGVi8PeYidqkEwvQSpavSjQUmUzTYtakjKTubr51xKjuPEVentYYCZwLApLnc9l7lHhameb0bJLT6f9kZ3XpmmfxxFd6Po9ucvo_SWflBN90T5OI7G08m15qet8jRK0pi-_PhAP5qGfjJ7mlEcYX8S4yue0y9fl5RESUxPs8lqkr35-cdPv4ySz0H0KFkS5ClHgrqia3yHc-OMCuFkRZUpt9LynoPyG2hNWqv2SstqLfFAshEFHnqDHzvn2WSL35LicT4Zxzgyy-dSVjORiGDRdRxfR_EomfeHtN7vaC-tY-9xOE77-a8bSaJttSoFB4YN7E3CmBVQaYWXNMoXVlZFW4_yO6jaeN86iIF3-Kxhc1eMS7PDQ20aZSoMhv1HA4bvEPg76Uqr2qBQFKbz5M_NeJ2ftxYeTKcr0moryRsSjdDPTgYBX5cP1ApE0p98qGTFB_HQGus5wvLJW1F62gurTOdINbWxu142PvcPkFkFWVo890lRTam7SjXroMaXLZlgvOPFZ9NRKRosqWZLpuZYtdHHgeI9w_d8_DpG7LBTO3hcK9j92vfaip08GLuFNuHJSh1cC6BRznUyAMxRbbQ2BzZ4EJwvkItVaSo59k_-Q9sYLcPPdWvNb7L0nFoAEi5_ns6yLMszjM6Evsl0-D5sZEPaiJfgnSU5lISVnJmweDJbWmusO5M3iYZPeLRyDdvvZuQ8Mo5RRIVEIiXNuD65HgqOLNmMsEo2_-jcdD6ci_pzOcaLcDT78OhsODqNX6kMIJ51s34wx5gXkkX0EqnvSJwOEpOKJaqaLOSkn8gmtDbAfVtCUjwEgx6jlcXxdosszFSFYYLomrrGKEailvY46HbiabUXupM8k8CWJQph1W9l558QvgVFT9My2Lx0abI6PxPEXJqd02Mc7Cj909GO6MUOHqndrh9ha3I0eSWb6uPtadiumv1DRI_ZW3fjl3NpPrgbBmfuTr7tbdp7Cz35d0Rnf030ZHU4uTDthxk9zlb28E2Vk7-mcn6MWozcYPWubiOq2-u8tyUa_nhqkr2bmibvpmbRUWIPvVZY2XgS2kpRPdNGVHQB1Ttht0M1z0KtOFHL_jnOEp54jP478Pu70fuHsNtHjIF77mV6AVvpWy_TOP-ml3FdX3Yzj-MLboZZBvkJh5OLkPwYj5M_h8dvoPEdFt8h8R0OX6NwABFf-tNwA8_DDZwcV9P_Q-x_B2LHWzb520GWnv-bz3_nv3lIEFqhkytL6Rx3rX2Xyg3QMTXo-P4thzhwDr-fvUHwY8bnnQy8Am20U5XkDpR7qUFFf0lbw5rRKaJQ0M26xrEbWu3Qf8W9v-wRxxqXtpdu1Uq74o0UwV4v9DBPc2ql2J6e-GZf8d1P04t92uu2_75RXgk99Oyq7z1Pjf6v3Cseu3N2Qeq6b20rWXTrs0adG09T_FZ1u7bvPZd0TyUzA7SVU0-1Qg_PMsAuMCo3stwSAiUb9xKhU7eJ6K1NgxlrdmHp0w-fxxebT6ZEQ1JrJgKrngisWsMRXVAcmrRKeMFlS6PpYujQ8FcgTPh3OMyMpncDM0P6Bkmv8PRGtmDxtyUoh6duxgB4kXMp3ve07hhqSO8BRyHomllW1Vl2Fz1-C63HljzQPIAyUMT7R-KGHsGx5MwOq1K4QBl7ydf0BWxIvnBZyNohH63wXlrQx4aWtHj4zAnxG4Ok9LSo394Yz7YwVIOCJavF7qByfFQAm9ABo6-gf3UK3FOAQHhOWsilsM9DOlnCmzAN3XO5Ec366F64PAJTe0mvxnIn1igSEOIW5EbtZW8xjNyp9QYEUgZrG8mFA52Bm29AgI6uHBfYhZ0AGXWd7WkoO4QeSDlEZKhPpsPQCcuMtUymBlfva4btJiwFdlSY_Rs-3oSFUZIA-eXm6DC_FEDrFYDPcZACayVIbyjsE18Fjf354evqy-3ynz1l3AAOGbiwc6rQp-DMqRtItEbILYq06XYF7Gco8jm4vG3MoTliiLcyjhARSy2kShaCWHRtxS8MBqL8OjlWcGbZjGZIjFX8WoM06r4Pv2zeksS-qDkdrQg3WPEctvTvazjUe2mZKNtA2wM3xnWHxOrnMS0AtI6vDd81sEqHNIoqhMYEa16r0matygG5iEa4ilC1ogHeHG4irWEqbjp4GfhpIPtJwkZA5RrcnMPkDUpJ2PDiZnxelMMrgqEaA9pKizuxRLwDuK9PyGapocJag1sr3Ju4BMdX1U1azdO5uPLKa3kDZs_llt_1Zcyn-CY7FzsUjHIv1Xf0g6k51UJpgPeqs_rmD78UCK8d-K1AnsZJfLW5EVmVl4mo47mUZSXTYjbJijrN5mWelmlcX2lRSO3YckSokYf-zQXG8OJK3SRRkkRxHEfTJMuTcT2tUxY0K6QsppP5KIvkDgaP2Y6xsesrexNMQnQcFjXqzp0WARq1bmQIFMsXHZJrb7Zyr65d11wF3TfB9v8AJG8Zow">