We have seen a few syzkaller reports of locking violations triggered by map_delete from sockmap/sockhash from an unexpected code path, for instance when irqs were disabled, or during a kfree inside a map_update. The consensus is [1] to block map_delete op in the verifier for programs which are not allowed to update sockmap/sockhash already today, instead of trying to make sockmap deletes lock-safe in every possible context. [1] https://lore.kernel.org/r/87a5kfwe8l.fsf@xxxxxxxxxxxxxx --- Cc: Alexei Starovoitov <ast@xxxxxxxxxx> Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx> Cc: John Fastabend <john.fastabend@xxxxxxxxx> Cc: Hillf Danton <hdanton@xxxxxxxx> Cc: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> --- Jakub Sitnicki (3): bpf: Allow delete from sockmap/sockhash only if update is allowed Revert "bpf, sockmap: Prevent lock inversion deadlock in map delete elem" selftests/bpf: Cover verifier checks for mutating sockmap/sockhash kernel/bpf/verifier.c | 10 +- net/core/sock_map.c | 6 - tools/testing/selftests/bpf/prog_tests/verifier.c | 2 + .../selftests/bpf/progs/verifier_sockmap_mutate.c | 187 +++++++++++++++++++++ 4 files changed, 196 insertions(+), 9 deletions(-)
