[PATCH] lsm: Fix the crash issue in xfrm_decode_session

[PATCH] lsm: Fix the crash issue in xfrm_decode_session

[Feng Yang]

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:

[  112.838874] ------------[ cut here ]------------
[  112.838895] kernel BUG at security/security.c:5282!
[  112.838902] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[  112.838905] CPU: 5 PID: 4962 Comm: test Kdump: loaded Not tainted 6.19.0-rc5-gae23bc81ddf7 #2 PREEMPT(full)
[  112.838907] Source Version: 55e2f799c748c8e195569363edbd1d6a4159675a
[  112.838908] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[  112.838909] RIP: 0010:security_skb_classify_flow+0x3f/0x50
[  112.838914] Code: 85 db 74 28 49 89 fc 48 8d 6e 14 eb 08 48 8b 1b 48 85 db 74 17 31 d2 48 8b 43 18 48 89 ee 4c 89 e7 e8 05 33 86 00 85 c0 74 e3 <0f> 0b 5b 5d 41 5c c3 cc cc cc cc 66 0f 1f 44 00 00 90 90 90 90 90
[  112.838915] RSP: 0018:ffffc28400200b10 EFLAGS: 00010202
[  112.838918] RAX: 0000000000000001 RBX: ffffffff91d346d8 RCX: 0000000000000000
[  112.838919] RDX: ffffa0890f5eaf80 RSI: 0000000000000001 RDI: ffffa0890f5eaf80
[  112.838920] RBP: ffffc28400200d04 R08: 00000000000000c7 R09: 0000000000000002
[  112.838922] R10: 0000000000000000 R11: 000000000000000f R12: ffffa089086dedc0
[  112.838923] R13: ffffc28400200cf0 R14: ffffa08901ab2000 R15: 0000000000000000
[  112.838926] FS:  00007fb087dd2680(0000) GS:ffffa0891ba80000(0000) knlGS:0000000000000000
[  112.838927] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  112.838929] CR2: 00007fb087d1b940 CR3: 0000000107520006 CR4: 00000000000706e0
[  112.838930] Call Trace:
[  112.838931]  <IRQ>
[  112.838933]  icmp_route_lookup.constprop.0+0xd7/0x460
[  112.838941]  ? switch_hrtimer_base+0x135/0x180
[  112.838944]  ? update_sg_lb_stats+0x9c/0x440
[  112.838949]  __icmp_send+0x3d3/0x740
[  112.838952]  ? __udp4_lib_rcv+0x427/0x6f0
[  112.838955]  __udp4_lib_rcv+0x427/0x6f0
[  112.838957]  ip_protocol_deliver_rcu+0xb7/0x170
[  112.838960]  ip_local_deliver_finish+0x76/0xa0
[  112.838961]  __netif_receive_skb_one_core+0x89/0xa0
[  112.838967]  process_backlog+0x95/0x140
[  112.838969]  __napi_poll+0x2b/0x1c0
[  112.838971]  net_rx_action+0x2aa/0x3a0
[  112.838972]  ? swake_up_one+0x41/0x70
[  112.838974]  ? kvm_sched_clock_read+0x11/0x20
[  112.838977]  handle_softirqs+0xe3/0x2e0
[  112.838980]  do_softirq+0x43/0x60
[  112.838982]  </IRQ>
[  112.838982]  <TASK>
[  112.838983]  __local_bh_enable_ip+0x68/0x70
[  112.838985]  __dev_queue_xmit+0x1c4/0x820
[  112.838987]  ? nf_hook_slow+0x45/0xd0
[  112.838989]  ip_finish_output2+0x1da/0x4a0
[  112.838992]  ip_send_skb+0x86/0x90
[  112.838994]  udp_send_skb+0x15e/0x380
[  112.838996]  udp_sendmsg+0xb9a/0xf80
[  112.838998]  ? __pfx_ip_generic_getfrag+0x10/0x10
[  112.839003]  ? __sys_sendto+0x1e4/0x210
[  112.839005]  __sys_sendto+0x1e4/0x210
[  112.839007]  ? __handle_mm_fault+0x2fc/0x6c0
[  112.839013]  __x64_sys_sendto+0x24/0x30
[  112.839014]  do_syscall_64+0x5f/0x270
[  112.839017]  entry_SYSCALL_64_after_hwframe+0x76/0xe0
[  112.839020] RIP: 0033:0x7fb087cfdb17
[  112.839021] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 55 c8 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44
[  112.839023] RSP: 002b:00007ffea64704e8 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[  112.839025] RAX: ffffffffffffffda RBX: 00007ffea6470638 RCX: 00007fb087cfdb17
[  112.839026] RDX: 0000000000000008 RSI: 00007ffea64704f8 RDI: 0000000000000003
[  112.839027] RBP: 00007ffea6470520 R08: 00007ffea6470500 R09: 0000000000000010
[  112.839029] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
[  112.839030] R13: 00007ffea6470648 R14: 0000000000403df0 R15: 00007fb087e15000
[  112.839032]  </TASK>

This BUG_ON was first mentioned in [1], but I could not find any explanatory record of why this check is needed.

[1] https://lore.kernel.org/all/Pine.LNX.4.64.0607122149070.573@d.namei/

In the existing LSM_HOOK_INIT(xfrm_decode_session, selinux_xfrm_decode_session),
when the `ckall` parameter of the `selinux_xfrm_decode_session` function is 0,
it can only return 0 and will not trigger BUG_ON.
Therefore, remove the BUG_ON check to fix this issue.

Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
Closes: https://lore.kernel.org/all/4c4d04ba.6c12b.19c039b69e6.Coremail.kaiyanm@hust.edu.cn/
Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
---
 security/security.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/security/security.c b/security/security.c
index 67af9228c4e9..198f650070da 100644
--- a/security/security.c
+++ b/security/security.c
@@ -4991,10 +4991,7 @@ int security_xfrm_decode_session(struct sk_buff *skb, u32 *secid)
 
 void security_skb_classify_flow(struct sk_buff *skb, struct flowi_common *flic)
 {
-	int rc = call_int_hook(xfrm_decode_session, skb, &flic->flowic_secid,
-			       0);
-
-	BUG_ON(rc);
+	call_int_hook(xfrm_decode_session, skb, &flic->flowic_secid, 0);
 }
 EXPORT_SYMBOL(security_skb_classify_flow);
 #endif	/* CONFIG_SECURITY_NETWORK_XFRM */
-- 
2.43.0

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

[Feng Yang]

> 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

There is an error here. Any error value between -4095 and -1 will trigger this bug,
while other values in the range [-4095, 0] will be rejected by the validator.

> }

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

[Casey Schaufler]

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.

>
> [  112.838874] ------------[ cut here ]------------
> [  112.838895] kernel BUG at security/security.c:5282!
> [  112.838902] invalid opcode: 0000 [#1] PREEMPT SMP PTI
> [  112.838905] CPU: 5 PID: 4962 Comm: test Kdump: loaded Not tainted 6.19.0-rc5-gae23bc81ddf7 #2 PREEMPT(full)
> [  112.838907] Source Version: 55e2f799c748c8e195569363edbd1d6a4159675a
> [  112.838908] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
> [  112.838909] RIP: 0010:security_skb_classify_flow+0x3f/0x50
> [  112.838914] Code: 85 db 74 28 49 89 fc 48 8d 6e 14 eb 08 48 8b 1b 48 85 db 74 17 31 d2 48 8b 43 18 48 89 ee 4c 89 e7 e8 05 33 86 00 85 c0 74 e3 <0f> 0b 5b 5d 41 5c c3 cc cc cc cc 66 0f 1f 44 00 00 90 90 90 90 90
> [  112.838915] RSP: 0018:ffffc28400200b10 EFLAGS: 00010202
> [  112.838918] RAX: 0000000000000001 RBX: ffffffff91d346d8 RCX: 0000000000000000
> [  112.838919] RDX: ffffa0890f5eaf80 RSI: 0000000000000001 RDI: ffffa0890f5eaf80
> [  112.838920] RBP: ffffc28400200d04 R08: 00000000000000c7 R09: 0000000000000002
> [  112.838922] R10: 0000000000000000 R11: 000000000000000f R12: ffffa089086dedc0
> [  112.838923] R13: ffffc28400200cf0 R14: ffffa08901ab2000 R15: 0000000000000000
> [  112.838926] FS:  00007fb087dd2680(0000) GS:ffffa0891ba80000(0000) knlGS:0000000000000000
> [  112.838927] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  112.838929] CR2: 00007fb087d1b940 CR3: 0000000107520006 CR4: 00000000000706e0
> [  112.838930] Call Trace:
> [  112.838931]  <IRQ>
> [  112.838933]  icmp_route_lookup.constprop.0+0xd7/0x460
> [  112.838941]  ? switch_hrtimer_base+0x135/0x180
> [  112.838944]  ? update_sg_lb_stats+0x9c/0x440
> [  112.838949]  __icmp_send+0x3d3/0x740
> [  112.838952]  ? __udp4_lib_rcv+0x427/0x6f0
> [  112.838955]  __udp4_lib_rcv+0x427/0x6f0
> [  112.838957]  ip_protocol_deliver_rcu+0xb7/0x170
> [  112.838960]  ip_local_deliver_finish+0x76/0xa0
> [  112.838961]  __netif_receive_skb_one_core+0x89/0xa0
> [  112.838967]  process_backlog+0x95/0x140
> [  112.838969]  __napi_poll+0x2b/0x1c0
> [  112.838971]  net_rx_action+0x2aa/0x3a0
> [  112.838972]  ? swake_up_one+0x41/0x70
> [  112.838974]  ? kvm_sched_clock_read+0x11/0x20
> [  112.838977]  handle_softirqs+0xe3/0x2e0
> [  112.838980]  do_softirq+0x43/0x60
> [  112.838982]  </IRQ>
> [  112.838982]  <TASK>
> [  112.838983]  __local_bh_enable_ip+0x68/0x70
> [  112.838985]  __dev_queue_xmit+0x1c4/0x820
> [  112.838987]  ? nf_hook_slow+0x45/0xd0
> [  112.838989]  ip_finish_output2+0x1da/0x4a0
> [  112.838992]  ip_send_skb+0x86/0x90
> [  112.838994]  udp_send_skb+0x15e/0x380
> [  112.838996]  udp_sendmsg+0xb9a/0xf80
> [  112.838998]  ? __pfx_ip_generic_getfrag+0x10/0x10
> [  112.839003]  ? __sys_sendto+0x1e4/0x210
> [  112.839005]  __sys_sendto+0x1e4/0x210
> [  112.839007]  ? __handle_mm_fault+0x2fc/0x6c0
> [  112.839013]  __x64_sys_sendto+0x24/0x30
> [  112.839014]  do_syscall_64+0x5f/0x270
> [  112.839017]  entry_SYSCALL_64_after_hwframe+0x76/0xe0
> [  112.839020] RIP: 0033:0x7fb087cfdb17
> [  112.839021] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 55 c8 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44
> [  112.839023] RSP: 002b:00007ffea64704e8 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
> [  112.839025] RAX: ffffffffffffffda RBX: 00007ffea6470638 RCX: 00007fb087cfdb17
> [  112.839026] RDX: 0000000000000008 RSI: 00007ffea64704f8 RDI: 0000000000000003
> [  112.839027] RBP: 00007ffea6470520 R08: 00007ffea6470500 R09: 0000000000000010
> [  112.839029] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
> [  112.839030] R13: 00007ffea6470648 R14: 0000000000403df0 R15: 00007fb087e15000
> [  112.839032]  </TASK>
>
> This BUG_ON was first mentioned in [1], but I could not find any explanatory record of why this check is needed.
>
> [1] https://lore.kernel.org/all/Pine.LNX.4.64.0607122149070.573@d.namei/
>
> In the existing LSM_HOOK_INIT(xfrm_decode_session, selinux_xfrm_decode_session),
> when the `ckall` parameter of the `selinux_xfrm_decode_session` function is 0,
> it can only return 0 and will not trigger BUG_ON.
> Therefore, remove the BUG_ON check to fix this issue.
>
> Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
> Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
> Closes: https://lore.kernel.org/all/4c4d04ba.6c12b.19c039b69e6.Coremail.kaiyanm@hust.edu.cn/
> Signed-off-by: Feng Yang <yangfeng@kylinos.cn>
> ---
>  security/security.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/security/security.c b/security/security.c
> index 67af9228c4e9..198f650070da 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -4991,10 +4991,7 @@ int security_xfrm_decode_session(struct sk_buff *skb, u32 *secid)
>  
>  void security_skb_classify_flow(struct sk_buff *skb, struct flowi_common *flic)
>  {
> -	int rc = call_int_hook(xfrm_decode_session, skb, &flic->flowic_secid,
> -			       0);
> -
> -	BUG_ON(rc);
> +	call_int_hook(xfrm_decode_session, skb, &flic->flowic_secid, 0);
>  }
>  EXPORT_SYMBOL(security_skb_classify_flow);
>  #endif	/* CONFIG_SECURITY_NETWORK_XFRM */

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

[Feng Yang]

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.

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? 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.

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

[Casey Schaufler]

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.
>
>

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

[Stephen Smalley]

On Thu, Mar 19, 2026 at 1:52 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> 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.

Looks like this BUG_ON() has just been preserved since first being
introduced by:
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=beb8d13bed80f8388f1a9a107d07ddd342e627e8

I think we can remove it at this point - it evidently doesn't ever
trigger for SELinux or we would have seen it by now and it is
definitely unsafe for BPF LSM.

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

[Feng Yang]

On Thu, 19 Mar 2026 10:51:24 -0700, Casey Schaufler wrote:
> 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?

Yes.

> 
> > 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.
> >
> >

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

[Feng Yang]

On Thu, 19 Mar 2026 14:22:06 -0400, Stephen Smalley wrote:
> On Thu, Mar 19, 2026 at 1:52 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> > 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.
> 
> Looks like this BUG_ON() has just been preserved since first being
> introduced by:
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=beb8d13bed80f8388f1a9a107d07ddd342e627e8

Yes, there is a comment in https://lore.kernel.org/all/Pine.LNX.4.64.0607122149070.573@d.namei/:

	+static inline void security_xfrm_skb_secid(struct sk_buff *skb, u32 *secid)
	{
	-	return security_ops->xfrm_decode_session(skb, fl);
	+	BUG_ON(security_ops->xfrm_decode_session(skb, secid, 0));

	BUG_ON looks wrong here, in that you don't know why the LSM returned an 
	error, and why should the box panic at this point at all?

But it seems no one has answered this question before.

> I think we can remove it at this point - it evidently doesn't ever
> trigger for SELinux or we would have seen it by now and it is
> definitely unsafe for BPF LSM.

Yes, the call in the SELinux module is as follows.

void security_skb_classify_flow(struct sk_buff *skb, struct flowi_common *flic)
{
	int rc = call_int_hook(xfrm_decode_session, skb, &flic->flowic_secid,
			       0);

	BUG_ON(rc);
}

int selinux_xfrm_decode_session(struct sk_buff *skb, u32 *sid, int ckall)
{
	if (skb == NULL) {
		*sid = SECSID_NULL;
		return 0;
	}
	return selinux_xfrm_skb_sid_ingress(skb, sid, ckall);
}

static int selinux_xfrm_skb_sid_ingress(struct sk_buff *skb,
					u32 *sid, int ckall)
{
	u32 sid_session = SECSID_NULL;
	struct sec_path *sp = skb_sec_path(skb);

	if (sp) {
		int i;

		for (i = sp->len - 1; i >= 0; i--) {
			struct xfrm_state *x = sp->xvec[i];
			if (selinux_authorizable_xfrm(x)) {
				struct xfrm_sec_ctx *ctx = x->security;

				if (sid_session == SECSID_NULL) {
					sid_session = ctx->ctx_sid;
					if (!ckall)
						goto out;
				} else if (sid_session != ctx->ctx_sid) {
					*sid = SECSID_NULL;
					return -EINVAL;
				}
			}
		}
	}

out:
	*sid = sid_session;
	return 0;
}

Since ckall is 0, selinux_xfrm_skb_sid_ingress will only return 0.
Therefore, the selinux_xfrm_decode_session function will only return 0 when ckall is 0, and BUG_ON will never be triggered.

However, BPF can be exploited to cause a system crash.

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

[Feng Yang]

On Thu, 19 Mar 2026 14:22:06 -0400, Stephen Smalley wrote:
> On Thu, Mar 19, 2026 at 1:52 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> > 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.
> 
> Looks like this BUG_ON() has just been preserved since first being
> introduced by:
> https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=beb8d13bed80f8388f1a9a107d07ddd342e627e8

Yes, there is a comment in https://lore.kernel.org/all/Pine.LNX.4.64.0607122149070.573@d.namei/:

	+static inline void security_xfrm_skb_secid(struct sk_buff *skb, u32 *secid)
	{
	-	return security_ops->xfrm_decode_session(skb, fl);
	+	BUG_ON(security_ops->xfrm_decode_session(skb, secid, 0));

	BUG_ON looks wrong here, in that you don't know why the LSM returned an 
	error, and why should the box panic at this point at all?

But it seems no one has answered this question before.

> I think we can remove it at this point - it evidently doesn't ever
> trigger for SELinux or we would have seen it by now and it is
> definitely unsafe for BPF LSM.

Yes, the call in the SELinux module is as follows.

void security_skb_classify_flow(struct sk_buff *skb, struct flowi_common *flic)
{
	int rc = call_int_hook(xfrm_decode_session, skb, &flic->flowic_secid,
			       0);

	BUG_ON(rc);
}

int selinux_xfrm_decode_session(struct sk_buff *skb, u32 *sid, int ckall)
{
	if (skb == NULL) {
		*sid = SECSID_NULL;
		return 0;
	}
	return selinux_xfrm_skb_sid_ingress(skb, sid, ckall);
}

static int selinux_xfrm_skb_sid_ingress(struct sk_buff *skb,
					u32 *sid, int ckall)
{
	u32 sid_session = SECSID_NULL;
	struct sec_path *sp = skb_sec_path(skb);

	if (sp) {
		int i;

		for (i = sp->len - 1; i >= 0; i--) {
			struct xfrm_state *x = sp->xvec[i];
			if (selinux_authorizable_xfrm(x)) {
				struct xfrm_sec_ctx *ctx = x->security;

				if (sid_session == SECSID_NULL) {
					sid_session = ctx->ctx_sid;
					if (!ckall)
						goto out;
				} else if (sid_session != ctx->ctx_sid) {
					*sid = SECSID_NULL;
					return -EINVAL;
				}
			}
		}
	}

out:
	*sid = sid_session;
	return 0;
}

Since ckall is 0, selinux_xfrm_skb_sid_ingress will only return 0.
Therefore, the selinux_xfrm_decode_session function will only return 0 when ckall is 0, and BUG_ON will never be triggered.

However, BPF can be exploited to cause a system crash.