0001
0002 =============
0003 eBPF verifier
0004 =============
0005
0006 The safety of the eBPF program is determined in two steps.
0007
0008 First step does DAG check to disallow loops and other CFG validation.
0009 In particular it will detect programs that have unreachable instructions.
0010 (though classic BPF checker allows them)
0011
0012 Second step starts from the first insn and descends all possible paths.
0013 It simulates execution of every insn and observes the state change of
0014 registers and stack.
0015
0016 At the start of the program the register R1 contains a pointer to context
0017 and has type PTR_TO_CTX.
0018 If verifier sees an insn that does R2=R1, then R2 has now type
0019 PTR_TO_CTX as well and can be used on the right hand side of expression.
0020 If R1=PTR_TO_CTX and insn is R2=R1+R1, then R2=SCALAR_VALUE,
0021 since addition of two valid pointers makes invalid pointer.
0022 (In 'secure' mode verifier will reject any type of pointer arithmetic to make
0023 sure that kernel addresses don't leak to unprivileged users)
0024
0025 If register was never written to, it's not readable::
0026
0027 bpf_mov R0 = R2
0028 bpf_exit
0029
0030 will be rejected, since R2 is unreadable at the start of the program.
0031
0032 After kernel function call, R1-R5 are reset to unreadable and
0033 R0 has a return type of the function.
0034
0035 Since R6-R9 are callee saved, their state is preserved across the call.
0036
0037 ::
0038
0039 bpf_mov R6 = 1
0040 bpf_call foo
0041 bpf_mov R0 = R6
0042 bpf_exit
0043
0044 is a correct program. If there was R1 instead of R6, it would have
0045 been rejected.
0046
0047 load/store instructions are allowed only with registers of valid types, which
0048 are PTR_TO_CTX, PTR_TO_MAP, PTR_TO_STACK. They are bounds and alignment checked.
0049 For example::
0050
0051 bpf_mov R1 = 1
0052 bpf_mov R2 = 2
0053 bpf_xadd *(u32 *)(R1 + 3) += R2
0054 bpf_exit
0055
0056 will be rejected, since R1 doesn't have a valid pointer type at the time of
0057 execution of instruction bpf_xadd.
0058
0059 At the start R1 type is PTR_TO_CTX (a pointer to generic ``struct bpf_context``)
0060 A callback is used to customize verifier to restrict eBPF program access to only
0061 certain fields within ctx structure with specified size and alignment.
0062
0063 For example, the following insn::
0064
0065 bpf_ld R0 = *(u32 *)(R6 + 8)
0066
0067 intends to load a word from address R6 + 8 and store it into R0
0068 If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know
0069 that offset 8 of size 4 bytes can be accessed for reading, otherwise
0070 the verifier will reject the program.
0071 If R6=PTR_TO_STACK, then access should be aligned and be within
0072 stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8,
0073 so it will fail verification, since it's out of bounds.
0074
0075 The verifier will allow eBPF program to read data from stack only after
0076 it wrote into it.
0077
0078 Classic BPF verifier does similar check with M[0-15] memory slots.
0079 For example::
0080
0081 bpf_ld R0 = *(u32 *)(R10 - 4)
0082 bpf_exit
0083
0084 is invalid program.
0085 Though R10 is correct read-only register and has type PTR_TO_STACK
0086 and R10 - 4 is within stack bounds, there were no stores into that location.
0087
0088 Pointer register spill/fill is tracked as well, since four (R6-R9)
0089 callee saved registers may not be enough for some programs.
0090
0091 Allowed function calls are customized with bpf_verifier_ops->get_func_proto()
0092 The eBPF verifier will check that registers match argument constraints.
0093 After the call register R0 will be set to return type of the function.
0094
0095 Function calls is a main mechanism to extend functionality of eBPF programs.
0096 Socket filters may let programs to call one set of functions, whereas tracing
0097 filters may allow completely different set.
0098
0099 If a function made accessible to eBPF program, it needs to be thought through
0100 from safety point of view. The verifier will guarantee that the function is
0101 called with valid arguments.
0102
0103 seccomp vs socket filters have different security restrictions for classic BPF.
0104 Seccomp solves this by two stage verifier: classic BPF verifier is followed
0105 by seccomp verifier. In case of eBPF one configurable verifier is shared for
0106 all use cases.
0107
0108 See details of eBPF verifier in kernel/bpf/verifier.c
0109
0110 Register value tracking
0111 =======================
0112
0113 In order to determine the safety of an eBPF program, the verifier must track
0114 the range of possible values in each register and also in each stack slot.
0115 This is done with ``struct bpf_reg_state``, defined in include/linux/
0116 bpf_verifier.h, which unifies tracking of scalar and pointer values. Each
0117 register state has a type, which is either NOT_INIT (the register has not been
0118 written to), SCALAR_VALUE (some value which is not usable as a pointer), or a
0119 pointer type. The types of pointers describe their base, as follows:
0120
0121
0122 PTR_TO_CTX
0123 Pointer to bpf_context.
0124 CONST_PTR_TO_MAP
0125 Pointer to struct bpf_map. "Const" because arithmetic
0126 on these pointers is forbidden.
0127 PTR_TO_MAP_VALUE
0128 Pointer to the value stored in a map element.
0129 PTR_TO_MAP_VALUE_OR_NULL
0130 Either a pointer to a map value, or NULL; map accesses
0131 (see maps.rst) return this type, which becomes a
0132 PTR_TO_MAP_VALUE when checked != NULL. Arithmetic on
0133 these pointers is forbidden.
0134 PTR_TO_STACK
0135 Frame pointer.
0136 PTR_TO_PACKET
0137 skb->data.
0138 PTR_TO_PACKET_END
0139 skb->data + headlen; arithmetic forbidden.
0140 PTR_TO_SOCKET
0141 Pointer to struct bpf_sock_ops, implicitly refcounted.
0142 PTR_TO_SOCKET_OR_NULL
0143 Either a pointer to a socket, or NULL; socket lookup
0144 returns this type, which becomes a PTR_TO_SOCKET when
0145 checked != NULL. PTR_TO_SOCKET is reference-counted,
0146 so programs must release the reference through the
0147 socket release function before the end of the program.
0148 Arithmetic on these pointers is forbidden.
0149
0150 However, a pointer may be offset from this base (as a result of pointer
0151 arithmetic), and this is tracked in two parts: the 'fixed offset' and 'variable
0152 offset'. The former is used when an exactly-known value (e.g. an immediate
0153 operand) is added to a pointer, while the latter is used for values which are
0154 not exactly known. The variable offset is also used in SCALAR_VALUEs, to track
0155 the range of possible values in the register.
0156
0157 The verifier's knowledge about the variable offset consists of:
0158
0159 * minimum and maximum values as unsigned
0160 * minimum and maximum values as signed
0161
0162 * knowledge of the values of individual bits, in the form of a 'tnum': a u64
0163 'mask' and a u64 'value'. 1s in the mask represent bits whose value is unknown;
0164 1s in the value represent bits known to be 1. Bits known to be 0 have 0 in both
0165 mask and value; no bit should ever be 1 in both. For example, if a byte is read
0166 into a register from memory, the register's top 56 bits are known zero, while
0167 the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we
0168 then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0;
0169 0x1ff), because of potential carries.
0170
0171 Besides arithmetic, the register state can also be updated by conditional
0172 branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch
0173 it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false'
0174 branch it will have a umax_value of 8. A signed compare (with BPF_JSGT or
0175 BPF_JSGE) would instead update the signed minimum/maximum values. Information
0176 from the signed and unsigned bounds can be combined; for instance if a value is
0177 first tested < 8 and then tested s> 4, the verifier will conclude that the value
0178 is also > 4 and s< 8, since the bounds prevent crossing the sign boundary.
0179
0180 PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all
0181 pointers sharing that same variable offset. This is important for packet range
0182 checks: after adding a variable to a packet pointer register A, if you then copy
0183 it to another register B and then add a constant 4 to A, both registers will
0184 share the same 'id' but the A will have a fixed offset of +4. Then if A is
0185 bounds-checked and found to be less than a PTR_TO_PACKET_END, the register B is
0186 now known to have a safe range of at least 4 bytes. See 'Direct packet access',
0187 below, for more on PTR_TO_PACKET ranges.
0188
0189 The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of
0190 the pointer returned from a map lookup. This means that when one copy is
0191 checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs.
0192 As well as range-checking, the tracked information is also used for enforcing
0193 alignment of pointer accesses. For instance, on most systems the packet pointer
0194 is 2 bytes after a 4-byte alignment. If a program adds 14 bytes to that to jump
0195 over the Ethernet header, then reads IHL and addes (IHL * 4), the resulting
0196 pointer will have a variable offset known to be 4n+2 for some n, so adding the 2
0197 bytes (NET_IP_ALIGN) gives a 4-byte alignment and so word-sized accesses through
0198 that pointer are safe.
0199 The 'id' field is also used on PTR_TO_SOCKET and PTR_TO_SOCKET_OR_NULL, common
0200 to all copies of the pointer returned from a socket lookup. This has similar
0201 behaviour to the handling for PTR_TO_MAP_VALUE_OR_NULL->PTR_TO_MAP_VALUE, but
0202 it also handles reference tracking for the pointer. PTR_TO_SOCKET implicitly
0203 represents a reference to the corresponding ``struct sock``. To ensure that the
0204 reference is not leaked, it is imperative to NULL-check the reference and in
0205 the non-NULL case, and pass the valid reference to the socket release function.
0206
0207 Direct packet access
0208 ====================
0209
0210 In cls_bpf and act_bpf programs the verifier allows direct access to the packet
0211 data via skb->data and skb->data_end pointers.
0212 Ex::
0213
0214 1: r4 = *(u32 *)(r1 +80) /* load skb->data_end */
0215 2: r3 = *(u32 *)(r1 +76) /* load skb->data */
0216 3: r5 = r3
0217 4: r5 += 14
0218 5: if r5 > r4 goto pc+16
0219 R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp
0220 6: r0 = *(u16 *)(r3 +12) /* access 12 and 13 bytes of the packet */
0221
0222 this 2byte load from the packet is safe to do, since the program author
0223 did check ``if (skb->data + 14 > skb->data_end) goto err`` at insn #5 which
0224 means that in the fall-through case the register R3 (which points to skb->data)
0225 has at least 14 directly accessible bytes. The verifier marks it
0226 as R3=pkt(id=0,off=0,r=14).
0227 id=0 means that no additional variables were added to the register.
0228 off=0 means that no additional constants were added.
0229 r=14 is the range of safe access which means that bytes [R3, R3 + 14) are ok.
0230 Note that R5 is marked as R5=pkt(id=0,off=14,r=14). It also points
0231 to the packet data, but constant 14 was added to the register, so
0232 it now points to ``skb->data + 14`` and accessible range is [R5, R5 + 14 - 14)
0233 which is zero bytes.
0234
0235 More complex packet access may look like::
0236
0237
0238 R0=inv1 R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp
0239 6: r0 = *(u8 *)(r3 +7) /* load 7th byte from the packet */
0240 7: r4 = *(u8 *)(r3 +12)
0241 8: r4 *= 14
0242 9: r3 = *(u32 *)(r1 +76) /* load skb->data */
0243 10: r3 += r4
0244 11: r2 = r1
0245 12: r2 <<= 48
0246 13: r2 >>= 48
0247 14: r3 += r2
0248 15: r2 = r3
0249 16: r2 += 8
0250 17: r1 = *(u32 *)(r1 +80) /* load skb->data_end */
0251 18: if r2 > r1 goto pc+2
0252 R0=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=pkt_end R2=pkt(id=2,off=8,r=8) R3=pkt(id=2,off=0,r=8) R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)) R5=pkt(id=0,off=14,r=14) R10=fp
0253 19: r1 = *(u8 *)(r3 +4)
0254
0255 The state of the register R3 is R3=pkt(id=2,off=0,r=8)
0256 id=2 means that two ``r3 += rX`` instructions were seen, so r3 points to some
0257 offset within a packet and since the program author did
0258 ``if (r3 + 8 > r1) goto err`` at insn #18, the safe range is [R3, R3 + 8).
0259 The verifier only allows 'add'/'sub' operations on packet registers. Any other
0260 operation will set the register state to 'SCALAR_VALUE' and it won't be
0261 available for direct packet access.
0262
0263 Operation ``r3 += rX`` may overflow and become less than original skb->data,
0264 therefore the verifier has to prevent that. So when it sees ``r3 += rX``
0265 instruction and rX is more than 16-bit value, any subsequent bounds-check of r3
0266 against skb->data_end will not give us 'range' information, so attempts to read
0267 through the pointer will give "invalid access to packet" error.
0268
0269 Ex. after insn ``r4 = *(u8 *)(r3 +12)`` (insn #7 above) the state of r4 is
0270 R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) which means that upper 56 bits
0271 of the register are guaranteed to be zero, and nothing is known about the lower
0272 8 bits. After insn ``r4 *= 14`` the state becomes
0273 R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)), since multiplying an 8-bit
0274 value by constant 14 will keep upper 52 bits as zero, also the least significant
0275 bit will be zero as 14 is even. Similarly ``r2 >>= 48`` will make
0276 R2=inv(id=0,umax_value=65535,var_off=(0x0; 0xffff)), since the shift is not sign
0277 extending. This logic is implemented in adjust_reg_min_max_vals() function,
0278 which calls adjust_ptr_min_max_vals() for adding pointer to scalar (or vice
0279 versa) and adjust_scalar_min_max_vals() for operations on two scalars.
0280
0281 The end result is that bpf program author can access packet directly
0282 using normal C code as::
0283
0284 void *data = (void *)(long)skb->data;
0285 void *data_end = (void *)(long)skb->data_end;
0286 struct eth_hdr *eth = data;
0287 struct iphdr *iph = data + sizeof(*eth);
0288 struct udphdr *udp = data + sizeof(*eth) + sizeof(*iph);
0289
0290 if (data + sizeof(*eth) + sizeof(*iph) + sizeof(*udp) > data_end)
0291 return 0;
0292 if (eth->h_proto != htons(ETH_P_IP))
0293 return 0;
0294 if (iph->protocol != IPPROTO_UDP || iph->ihl != 5)
0295 return 0;
0296 if (udp->dest == 53 || udp->source == 9)
0297 ...;
0298
0299 which makes such programs easier to write comparing to LD_ABS insn
0300 and significantly faster.
0301
0302 Pruning
0303 =======
0304
0305 The verifier does not actually walk all possible paths through the program. For
0306 each new branch to analyse, the verifier looks at all the states it's previously
0307 been in when at this instruction. If any of them contain the current state as a
0308 subset, the branch is 'pruned' - that is, the fact that the previous state was
0309 accepted implies the current state would be as well. For instance, if in the
0310 previous state, r1 held a packet-pointer, and in the current state, r1 holds a
0311 packet-pointer with a range as long or longer and at least as strict an
0312 alignment, then r1 is safe. Similarly, if r2 was NOT_INIT before then it can't
0313 have been used by any path from that point, so any value in r2 (including
0314 another NOT_INIT) is safe. The implementation is in the function regsafe().
0315 Pruning considers not only the registers but also the stack (and any spilled
0316 registers it may hold). They must all be safe for the branch to be pruned.
0317 This is implemented in states_equal().
0318
0319 Understanding eBPF verifier messages
0320 ====================================
0321
0322 The following are few examples of invalid eBPF programs and verifier error
0323 messages as seen in the log:
0324
0325 Program with unreachable instructions::
0326
0327 static struct bpf_insn prog[] = {
0328 BPF_EXIT_INSN(),
0329 BPF_EXIT_INSN(),
0330 };
0331
0332 Error::
0333
0334 unreachable insn 1
0335
0336 Program that reads uninitialized register::
0337
0338 BPF_MOV64_REG(BPF_REG_0, BPF_REG_2),
0339 BPF_EXIT_INSN(),
0340
0341 Error::
0342
0343 0: (bf) r0 = r2
0344 R2 !read_ok
0345
0346 Program that doesn't initialize R0 before exiting::
0347
0348 BPF_MOV64_REG(BPF_REG_2, BPF_REG_1),
0349 BPF_EXIT_INSN(),
0350
0351 Error::
0352
0353 0: (bf) r2 = r1
0354 1: (95) exit
0355 R0 !read_ok
0356
0357 Program that accesses stack out of bounds::
0358
0359 BPF_ST_MEM(BPF_DW, BPF_REG_10, 8, 0),
0360 BPF_EXIT_INSN(),
0361
0362 Error::
0363
0364 0: (7a) *(u64 *)(r10 +8) = 0
0365 invalid stack off=8 size=8
0366
0367 Program that doesn't initialize stack before passing its address into function::
0368
0369 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
0370 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
0371 BPF_LD_MAP_FD(BPF_REG_1, 0),
0372 BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
0373 BPF_EXIT_INSN(),
0374
0375 Error::
0376
0377 0: (bf) r2 = r10
0378 1: (07) r2 += -8
0379 2: (b7) r1 = 0x0
0380 3: (85) call 1
0381 invalid indirect read from stack off -8+0 size 8
0382
0383 Program that uses invalid map_fd=0 while calling to map_lookup_elem() function::
0384
0385 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
0386 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
0387 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
0388 BPF_LD_MAP_FD(BPF_REG_1, 0),
0389 BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
0390 BPF_EXIT_INSN(),
0391
0392 Error::
0393
0394 0: (7a) *(u64 *)(r10 -8) = 0
0395 1: (bf) r2 = r10
0396 2: (07) r2 += -8
0397 3: (b7) r1 = 0x0
0398 4: (85) call 1
0399 fd 0 is not pointing to valid bpf_map
0400
0401 Program that doesn't check return value of map_lookup_elem() before accessing
0402 map element::
0403
0404 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
0405 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
0406 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
0407 BPF_LD_MAP_FD(BPF_REG_1, 0),
0408 BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
0409 BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0),
0410 BPF_EXIT_INSN(),
0411
0412 Error::
0413
0414 0: (7a) *(u64 *)(r10 -8) = 0
0415 1: (bf) r2 = r10
0416 2: (07) r2 += -8
0417 3: (b7) r1 = 0x0
0418 4: (85) call 1
0419 5: (7a) *(u64 *)(r0 +0) = 0
0420 R0 invalid mem access 'map_value_or_null'
0421
0422 Program that correctly checks map_lookup_elem() returned value for NULL, but
0423 accesses the memory with incorrect alignment::
0424
0425 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
0426 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
0427 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
0428 BPF_LD_MAP_FD(BPF_REG_1, 0),
0429 BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
0430 BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1),
0431 BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0),
0432 BPF_EXIT_INSN(),
0433
0434 Error::
0435
0436 0: (7a) *(u64 *)(r10 -8) = 0
0437 1: (bf) r2 = r10
0438 2: (07) r2 += -8
0439 3: (b7) r1 = 1
0440 4: (85) call 1
0441 5: (15) if r0 == 0x0 goto pc+1
0442 R0=map_ptr R10=fp
0443 6: (7a) *(u64 *)(r0 +4) = 0
0444 misaligned access off 4 size 8
0445
0446 Program that correctly checks map_lookup_elem() returned value for NULL and
0447 accesses memory with correct alignment in one side of 'if' branch, but fails
0448 to do so in the other side of 'if' branch::
0449
0450 BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0),
0451 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
0452 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
0453 BPF_LD_MAP_FD(BPF_REG_1, 0),
0454 BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
0455 BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2),
0456 BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0),
0457 BPF_EXIT_INSN(),
0458 BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 1),
0459 BPF_EXIT_INSN(),
0460
0461 Error::
0462
0463 0: (7a) *(u64 *)(r10 -8) = 0
0464 1: (bf) r2 = r10
0465 2: (07) r2 += -8
0466 3: (b7) r1 = 1
0467 4: (85) call 1
0468 5: (15) if r0 == 0x0 goto pc+2
0469 R0=map_ptr R10=fp
0470 6: (7a) *(u64 *)(r0 +0) = 0
0471 7: (95) exit
0472
0473 from 5 to 8: R0=imm0 R10=fp
0474 8: (7a) *(u64 *)(r0 +0) = 1
0475 R0 invalid mem access 'imm'
0476
0477 Program that performs a socket lookup then sets the pointer to NULL without
0478 checking it::
0479
0480 BPF_MOV64_IMM(BPF_REG_2, 0),
0481 BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8),
0482 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
0483 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
0484 BPF_MOV64_IMM(BPF_REG_3, 4),
0485 BPF_MOV64_IMM(BPF_REG_4, 0),
0486 BPF_MOV64_IMM(BPF_REG_5, 0),
0487 BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp),
0488 BPF_MOV64_IMM(BPF_REG_0, 0),
0489 BPF_EXIT_INSN(),
0490
0491 Error::
0492
0493 0: (b7) r2 = 0
0494 1: (63) *(u32 *)(r10 -8) = r2
0495 2: (bf) r2 = r10
0496 3: (07) r2 += -8
0497 4: (b7) r3 = 4
0498 5: (b7) r4 = 0
0499 6: (b7) r5 = 0
0500 7: (85) call bpf_sk_lookup_tcp#65
0501 8: (b7) r0 = 0
0502 9: (95) exit
0503 Unreleased reference id=1, alloc_insn=7
0504
0505 Program that performs a socket lookup but does not NULL-check the returned
0506 value::
0507
0508 BPF_MOV64_IMM(BPF_REG_2, 0),
0509 BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8),
0510 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
0511 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8),
0512 BPF_MOV64_IMM(BPF_REG_3, 4),
0513 BPF_MOV64_IMM(BPF_REG_4, 0),
0514 BPF_MOV64_IMM(BPF_REG_5, 0),
0515 BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp),
0516 BPF_EXIT_INSN(),
0517
0518 Error::
0519
0520 0: (b7) r2 = 0
0521 1: (63) *(u32 *)(r10 -8) = r2
0522 2: (bf) r2 = r10
0523 3: (07) r2 += -8
0524 4: (b7) r3 = 4
0525 5: (b7) r4 = 0
0526 6: (b7) r5 = 0
0527 7: (85) call bpf_sk_lookup_tcp#65
0528 8: (95) exit
0529 Unreleased reference id=1, alloc_insn=7
