search

retis-org / retis

Tracing packets in the Linux networking stack & friends
https://retis.readthedocs.io/en/stable/
100 stars 14 forks source link

ebpf: fix scratch memory area access. #211

Closed vlrpl closed 1 year ago

vlrpl commented 1 year ago

k is an offset inside a scratch area of 16 entries, 4 bytes-sized each. Apparently, the size slipped out. Fix it by taking it into account.

vlrpl commented 1 year ago

Any practical cases (you encountered) this fixes?

Apart from the small comment, LGTM.

Not really. AFAICT, more than one scratch memory location (assuming the first used is always M[0]) should be used for not that common filters. In my case, I realized the size was missing using "protochain GRE" while doing some experiments with the jump back generated by pcap_compile().

vlrpl commented 1 year ago

Any practical cases (you encountered) this fixes? Apart from the small comment, LGTM.

Not really. AFAICT, more than one scratch memory location (assuming the first used is always M[0]) should be used for not that common filters. In my case, I realized the size was missing using "protochain GRE" while doing some experiments with the jump back generated by pcap_compile().

e.g. a random filter like:

"(udp src port 53) or (vlan and tcp src port 80) or (icmp[icmptype] == icmp-echoreply && icmp[4:2] == 0xffdc)"

doesn't use M[] to st/ld data.