Type uint16 not supported in matchArgs in Tetragon versions above 1.4.1

[oyashiro-chama]

What happened? How can we reproduce this?

Hello! I found strange behaviour when experimented with policy for monitoring execution right granting via chmod syscall:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "chmod"
spec:
  kprobes:
  - call: "security_path_chmod"
    syscall: false
    return: false
    args:
    - index: 0
      type: "path"
    - index: 1
      type: "uint16"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/tmp/"
      - index: 1
        operator: "Mask"
        values:
        - "0111"

In function security_path_chmod second argument have type umode_t that don't have support in Tetragon, but in terms of size is unsigned short, so I assumed that it'll work. Policy able to generate events and value in that argument field is correct (tested on Tetragon 1.4.1). But argument filtration via Mask operator doesn't work as expected. So I decide to test it on newer versions, but on them tetragon refused to start with error:

Failed to execute tetragon" error="policy handler 'tracing' failed loading policy 'chmod': parseMatchArgs  error: writeMatchValues error: MatchArgs type uint16 unsupported

I tried to read release notes and issues but found no explanation. The issue starts with Tetragon version 1.5.0. In the end I was able to run policy on newer versions with type change from uint16 to uint32. In that case filter via Mask works and show correct results. Not sure how it right, but until there're no umode_t support as argument type, can't see other ways to do that.

Tetragon Version

1.5.0, 1.6.0

Kernel Version

Linux syft 6.1.0-31-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.128-1 (2025-02-07) x86_64 GNU/Linux

Kubernetes Version

Without Kubernetes

Bugtool

No response

Relevant log output

Anything else?

No response

[FedeDP]

Hi! Thanks for opening this issue! By looking at the code generating the error, i can see that u16 type is actually supported: https://github.com/cilium/tetragon/blob/main/pkg/selectors/kernel.go#L676 It resolves to: GenericU16Type: "uint16", string, therefore the parsing is correct.

I tested your policy with a locally built tetragon and it works fine, at least it loads without errors:

level=info msg="Loaded sensor successfully" sensor=generic_kprobe
level=info msg="Added TracingPolicy with success" TracingPolicy=test_tp.yaml metadata.namespace="" metadata.name=chmod

[oyashiro-chama]

@FedeDP Maybe I'll make some tests with build from main repository later next week. I found this function in 1.5.0 and 1.6.0, but it doesn't look like version from main repo, so this is reason behind error. Will it mean next release (maybe 1.7.0) include this fixes? Version 1.4.1 doesn't have code from main either but also lack default case in switch section. Maybe this is reason why it doesn't throw error but can't filter value either.

[FedeDP]

Yep this is something that was fixed a month ago: https://github.com/cilium/tetragon/commit/865de200bb75d2be7fd5605a9fb8d4b35f0132c6#diff-27cf3aef45267b713359a8b5e3cbf2932e0d809290418cc042c7f000d01dbdd2 and was not part of latest release! See pr: https://github.com/cilium/tetragon/pull/4171

[oyashiro-chama]

@FedeDP Hi! With version from main repo policy works as planned. In the end there're two separate problems: broken parsing of policy spec in releases 1.5.0 and 1.6.0 and broken support of uint16 in releases from 1.1.0 (where that type was added) to 1.4.1 (last release where we can load policy with that type). For now we'll use WA with uint32 and wait for 1.7.0 release. Maybe there're last question about this issue: Is there any need for another enhancement request for support umode_t? This type can be found in some functions that work with files. Or using compatible in size integer type is official way to do that?

[FedeDP]

Or using compatible in size integer type is official way to do that?

Am not really sure, let me ask @mtardy :) Anyway, since it is literally an unsigned short typedef, IMO adding its direct support is not worth it; but these are my 2c of course!

[mtardy]

Or using compatible in size integer type is official way to do that?

Am not really sure, let me ask @mtardy :) Anyway, since it is literally an unsigned short typedef, IMO adding its direct support is not worth it; but these are my 2c of course!

Yep I'd say there's little benefit to add types for type aliases like umode_t but if you have a specific use case in mind in which it would make sense that's always possible. So using an underlying type that allows you to see the arg value should do it for you?