Duplicate LSM hook entries cause event amplification while only the last entry is applied

[LiAlH4-SIGSEGV]

What happened? How can we reproduce this?

What happened?

When defining multiple lsmhooks entries with the same hook (file_open) in a single TracingPolicy, Tetragon posts events N times per matching event (where N is the number of duplicate lsmhooks entries), but only the selector from the final entry is applied.

Example: With the 3 duplicate file_open entries provided below:

• Opening /tmp/foo or /tmp/bar triggers no events.
• Opening /tmp/baz triggers 3 duplicate Post events.
• If a 4th entry were added, it would trigger 4 Post events for /tmp/baz.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "lsm-conflict-repro"
spec:
  lsmhooks:
    - hook: file_open
      args:
        - index: 0
          type: file
      selectors:
        - matchArgs:
            - args: [0]
              operator: Equal
              values: [/tmp/foo]
          matchActions:
            - action: Post
    - hook: file_open
      args:
        - index: 0
          type: file
      selectors:
        - matchArgs:
            - args: [0]
              operator: Equal
              values: [/tmp/bar]
          matchActions:
            - action: Post
    - hook: file_open
      args:
        - index: 0
          type: file
      selectors:
        - matchArgs:
            - args: [0]
              operator: Equal
              values: [/tmp/baz]
          matchActions:
            - action: Post

What I expected to happen

One of the following would be acceptable, but not the current behavior:

• Coexistence: each lsmhooks entry behaves independently (no “last selector wins”, and no duplication), or
• Fail fast: policy is rejected with a validation error explaining duplicate LSM hooks in one policy are unsupported.

Tetragon Version

v1.6.0

Kernel Version

6.18.6

Kubernetes Version

No response

Bugtool

No response

Relevant log output

Anything else?

Related Context

There have been prior discussions and fixes regarding duplicate-instance handling for kprobes (#2947 / PR #3121). This report highlights a similar issue specifically for LSM hooks, which additionally includes event amplification proportional to the number of entries. I have not yet confirmed if this also affects tracepoints.

Motivation

Currently, selectors are limited to 5 per hook. In production environments, it is common to require more than 5 independent match conditions for high-volume hooks. While splitting rules across multiple TracingPolicy objects is a viable workaround, being able to "shard" conditions across multiple entries in a single policy would significantly improve manageability.