CHIZI-0618:Samsung RKP/BPF JIT 触发 sing-ebpf 崩溃的绕过方案

sing-ebpf 在部分 Samsung vendor kernel 上触发的崩溃来自 ARM64 BPF JIT/RKP 集成,而非 maps、TC 或 socket 逻辑;共享拦截、TC socket_assign 和 ebpf status shared 应避免,临时可改用 local cgroup 或 TUN auto_route/auto_redirect,并向 Samsung 提交 panic 资料。

作者原文

Thanks for the detailed report and kernel analysis.

Based on the symptoms, this appears to be a Samsung vendor-kernel issue in the ARM64 BPF JIT/RKP integration, rather than a bug in sing-ebpf's maps, TC attachment, namespace handling, or socket-assignment logic.

The important differences are:

  • local cgroup mode works;
  • shared interception and TC socket_assign load BPF programs containing BPF-to-BPF subprograms;
  • the panic occurs during BPF_PROG_LOAD, inside build_prologue() / bpf_int_jit_compile();
  • the reported fault is a synchronous external abort while writing the JIT image.

This is consistent with the Samsung RKP hook protecting a JIT image before a later multipass/subprogram compilation pass writes to it. Since the device has CONFIG_BPF_JIT_ALWAYS_ON=y, disabling the JIT is not a practical workaround.

I do not plan to work around this by replacing the normal objects with fully inlined variants. That would significantly increase instruction size and verifier complexity, and could reduce compatibility with older Android/Linux kernels. A proper fix should be made in the Samsung kernel/RKP implementation, for example by protecting the JIT image only after the final compilation pass.

For now, please use one of these workarounds:

  • disable shared interception and TC socket_assign;
  • use local cgroup mode;
  • or use TUN with auto_route and auto_redirect.

Please report this to Samsung or the kernel maintainer together with the panic trace and the corresponding bpf_jit_comp.c source. ebpf status shared should also be avoided on this firmware because it loads the affected BPF object and may trigger the panic even before any program is attached.