public inbox for linux-security-module@vger.kernel.org
 help / color / mirror / Atom feed
From: Feng Yang <yangfeng59949@163.com>
To: paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com
Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] lsm: Fix the crash issue in xfrm_decode_session
Date: Wed, 18 Mar 2026 14:19:25 +0800	[thread overview]
Message-ID: <20260318061925.134954-1-yangfeng59949@163.com> (raw)

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


             reply	other threads:[~2026-03-18  6:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18  6:19 Feng Yang [this message]
2026-03-18  8:37 ` [PATCH] lsm: Fix the crash issue in xfrm_decode_session Feng Yang
2026-03-18 17:09 ` Casey Schaufler
2026-03-19  2:22   ` Feng Yang
2026-03-19 17:51     ` Casey Schaufler
2026-03-19 18:22       ` Stephen Smalley
2026-03-20  3:20         ` Feng Yang
2026-03-20  3:24         ` [PATCH RESEND] " Feng Yang
2026-03-20  3:03       ` [PATCH] " Feng Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260318061925.134954-1-yangfeng59949@163.com \
    --to=yangfeng59949@163.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox