Re: [PATCH] lsm: Fix the crash issue in xfrm_decode_session

[Casey Schaufler <casey@schaufler-ca.com>]

On 3/18/2026 7:22 PM, Feng Yang wrote:
> On Wed, 18 Mar 2026 10:09:47 -0700, Casey Schaufler wrote:
>> On 3/17/2026 11:19 PM, Feng Yang wrote:
>>> From: Feng Yang <yangfeng@kylinos.cn>
>>>
>>> After hooking the following BPF program:
>>> SEC("lsm/xfrm_decode_session")
>>> int BPF_PROG(lsm_hook_xfrm_decode_session, struct sk_buff *skb, u32 *secid, int ckall)
>>> {
>>>     return 1; // Any non-zero value
>>> }
>>> Subsequent packet transmission triggers will cause a kernel panic:
>> LSM hooks that use or provide secids cannot be stacked. That is,
>> you can't provide a BPF LSM hook and an SELinux LSM hook and expect
>> correct behavior. Your proposed "fix" removes a legitimate check.
> I'm very sorry, I didn't quite understand what you meant.
>
> Maybe my commit message wasn't clear. I only used a BPF LSM hook without SELinux stacking enabled.

Do i understand correctly that you do not have SELinux enabled?

> Therefore, is it the expected behavior that simply using
> SEC("lsm/xfrm_decode_session")
> int BPF_PROG(lsm_hook_xfrm_decode_session, struct sk_buff *skb, u32 *secid, int ckall) {
>     return -1;
> }
> would cause a kernel panic?

Yes. As the infrastructure is written, any return other than 0 is erroneous.
You will need to query the SELinux developers about why they decided to
implement the xfrm handling in this way.

>  If not, and if the BUG_ON check is still necessary,
> then does it mean we need to modify the return value validation logic in the BPF
> verifier to ensure that only BPF programs returning 0 are accepted for this hook?
>
> Thanks.
>
>